Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation

From: linux
Date: Thu Dec 15 2005 - 08:57:27 EST


Our Fearless Leader, in a fit of madness, intoned:
> A real semaphore is counting.
>
> Dammit, unless the pure mutex has a _huge_ performance advantage on major
> architectures, we're not changing it. There's absolutely zero point. A
> counting semaphore is a perfectly fine mutex - the fact that it can _also_
> be used to allow more than 1 user into a critical region and generally do
> other things is totally immaterial.

You're being thick today. Pay attention to the arguments.

A counting semaphore is NOT a perfectly fine mutex, and it SHOULD be changed.

People are indeed unhappy with the naming, and whether patching 95%
of the callers of up() and down() is a good idea is a valid and active
subject of debate. (For an out-of-tree -rt patch, is was certaintly
an extremely practical solution.)

But regardless of the eventual naming convention, mutexes are a good idea.
A mutex is *safer* than a counting semaphore. That's the main benefit.
Indeed, unless there's a performance advantage to a counting semaphore,
you should use a mutex!

It documents in the source what you're doing. Using a counting semaphore
for a mutex is as silly as using a float for a loop index. Even if
there isn't much speed penalty on modern processors.

Or perhaps I should compare it to using void * everywhere. That's a
perfectly fine pointer; why type-check it?

A separate mutex type allows extra error-checking. You can keep track
of the current holder (since there can be only one) and check that the
same person released it and didn't try to double-acquire it.

You can do priority inheritance, which is the main motivation for doing
this work in the -rt patches.

This isn't about speed, it's about bug-free code. And having a mutex
abstraction distinct from a general counting semaphore is damn useful
error-checking, even if it is simply a thin wrapper over a counting
semaphore. The only reason the code is full of counting semaphores
right now is that that's all people had.

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