Hello, On Fri, Jul 03, 2015 at 02:36:42PM +0200, Jan Kara wrote: > Let me phrase my objection this differently: Instead of implementing custom > synchronization mechanism, you could as well do: > > int count_submitted; /* Number of submitted works we want to wait for */ > struct completion done; > ... > submit works with 'done' as completion. > ... > while (count_submitted--) > wait_for_completion(&done); > > And we could also easily optimize that loop and put it in > kernel/sched/completion.c. The less synchronization mechanisms we have the > better I'd think... And what I'm trying to say is that we most likely don't want to build it around completions. We really don't want to roll "event count" and "wakeup count" into the same mechanism. There's nothing completion provides that such event counting mechanism needs or wants. It isn't that attractive from the completion side either. The main reason we have completions is for stupid simple synchronizations and we wanna keep it simple. I do agree that we might want a generic "event count" mechanism but at the same time combining a counter and wait_event is usually pretty trivial. Maybe atomic_t + waitqueue is a useful enough abstraction but then we would eventually end up having to deal with all the different types of waits and timeouts. We might end up with a lot of thin wrappers which really don't do much of anything. If you can think of a good way to abstract this, please go head. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
