[lkml]   [2002]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] scheduler fixes, 2.5.32-BK

On Fri, 30 Aug 2002, Ingo Molnar wrote:
> hm, indeed, you are right - completions are the only safe method.
> i'm starting to wonder whether it's possible at all (theoretically) to
> have a mutex design which has the current semaphore implementation's good
> fastpath properties, but could also be used on stack.

That's is my point. I don't think there is - although I suspect that many
architectures could easily do it. For all I know, there might well be some
tricks we could play on x86 with cmpxchg8b, for example.

But I simply think that our current "completion vs semaphore" split is a
pretty good one conceptually. They may _look_ like they are largely the
same operation, but they have pretty distinct behaviour both in what the
fast path is (ie "expected behaviour": semaphores expect to succeed,
completions expect to wait), and what the release criteria are (semaphores
do not guarantee that nobody looks at them after a down() has succeeded,
while completions do).

And one thing that tends to confirm my belief that "struct completion"
actually makes sense as a separate thing from a semaphore has nothing to
do with these implementation details. It's the much more conceptual one: a
lot of the cases where we converted to completions are just a lot more
_readable_ as completions.

Using a semaphore for much of it ("wait for the IO to complete" or "wait
for the thread to be set up") counted as a clever trick, but was a fairly
obscure clever trick. While the completion thing looks "obvious".

So even if the actual implementation of semaphores and completions were
100% the same, I would actually want to _keep_ this naming and conceptual
difference, simply because it just _looks_ cleaner, in my opinion.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.047 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site