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

[Linus Torvalds]

On Thu, 15 Dec 2005, linux@xxxxxxxxxxx wrote:
> 
> A counting semaphore is NOT a perfectly fine mutex, and it SHOULD be changed.

Don't be silly.

First off, the data structure is called a "semaphore", and always has 
been. It's _never_ been called a "mutex" in the first place, and the 
operations have been called "down()" and "up()", because I thought calling 
them P() and V() was just too damn traditional and confusing (I don't 
speak dutch, and even if I did, I think shortening names to that degree is 
just evil).

And dammit, a counting semaphore (and usually you don't even say the 
"counting" part, since counting is really always there) is just about 
_the_ classical mutual exclusion mechanism. If somebody doesn't know that, 
he has absolutely _no_ place talking about mutexes etc.

And a semaphore _is_ a mutex. Anybody who disputes that is just being a 
total troll. Even classically, the case where the semaphore was 
initialized to 1 is very very traditional, and is very much part of the 
whole point of a semaphore. Sometimes they are called "binary semaphores", 
but dammit, they are just the same thing.

A patch that
 - creates a non-counting mutex
 - .. that is SLOWER than the current counting one
 - .. and keeps the old "semaphore" and "up/down" naming

is simply INCREDIBLY BROKEN. It has absolutely _zero_ redeeming features. 
I can't understand how there are a hundred emails in my mailbox even 
discussing it. 

And I can't understand how somebody has the balls to even say that a 
semaphore isn't a mutex. That's like saying that an object of type "long" 
isn't an integer, because only "int" objects are integers. That's just 
INSANE.

> 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.)

Whatever people you claim are unhappy with the naming are
 - obviously totally unaware of very basic synchronization primitives
   used in concurrent programming
 - likely haven't spent any time at all looking at the kernel source code.
 - haven't _ever_ complained that I've seen before this totally made-up 
   discussion.

In other words, you are
 (a) totally making up the claim that people are really unhappy
 (b) jerking people around who _do_ know about semaphores and _have_ 
     worked with the kernel locking primitives and understand them well

So tell me, what do you think about your own arguments in that light?

> 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!

Hey, feel free to introduce a mutex, but DAMMIT, just call it that, 
instead of switching people over. 

And even then, it should damn well also:
 - really _be_ faster. On platforms that matter. 
 - have enough real other advantages that it's worth introducing another 
   abstraction, and more conceptual complexity. At least the RT patches 
   had a reason for them.

And besides, all your "safer" arguments are pretty damn pointless in the 
face of the fact that we have basically had zero bugs with the semaphores. 
This is not where the bugs happen. Yeah, yeah, double releases can happen, 
but it sure as hell isn't on my radar of things I remember people doing.

So when you say "This isn't about speed, this is about bug-free code", 
you're just making that up. It's doubly silly when your "safer" 
implementation uses totally illogical names. THAT is what creates bugs.

So go away.

Come back if you have pondered, and accepted reality, and perhaps have an 
acceptable patch that introduces a separate data structure. 

And no, we're not switching users over whole-sale. First you introduce the 
new concept. Only THEN can you can switch over INDIVIDUAL LOCKS with 
reasons for why it's worth it.

And hell yes, performance does matter.

			Linus
-
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/