Re: [patch] scheduler fixes, 2.5.32-BK

Linus Torvalds (torvalds@transmeta.com)
Fri, 30 Aug 2002 10:47:30 -0700 (PDT)


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.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/