The origin of completions is literally the semaphore code - just
simplified to use spinlocks and be usable as just a mutex. We used to use
semaphores, and because of the subtle race with lockless semaphores I
wrote that stupid completion code as a "generic semaphore with a very
specific usage schenario" and called them "completions".
The completions _could_ have been extended/used as mutex semaphores, but
the difference was really the mental model for them. That then limited the
implementation of them: the functions working on completions are defined
on purpose to be limited - it doesn't really have "up()" and "down()"
functions: "complete()" is really a up(), but "wait_for_completion()" is
more like a "wait_until_I_could_do_a_trydown()" function.
Would it make sense to use completions for countable events too? Yeah. In
fact, we have some things that really would like to do counting, both in
the sense of "wait for <n> events to all complete" _and_ in the sense of
"allow up to <n> events to be outstanding". Both of which could be done as
a counting function (just make "complete" increment the counter, and then
make "wait for <n> events" initialize it to negative, while "allow <n>
outstanding events" would be a positive counter, and make
"wait_for_completion()" basically be a "decrement and wait until it
is zero".
IOW, completions() really follow the same patterns as semaphores, and it
*does* make sense to just have one single code-base. But if we want to
make semaphores go away, I think that it would be better to implement
semaphores in terms of "extended completions" rather than the other way
around. That way, we could one day really get rid of semaphores entirely.
Linus
--
