Messages in this thread | | | Date | 15 Dec 2005 14:09:37 -0500 | From | linux@horizon ... | Subject | Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation |
| |
> 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.
I didn't say it isn't a mutex, I said it isn't a GOOD one!
The fundamental reason is that a semaphore doesn't have an owner, and a mutex does. And you can do a lot when you know who owns the lock.
>> 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.)
> In other words, you are > (a) totally making up the claim that people are really unhappy
Huh? I thought *you* were violently unhappy with the idea of naming mutex acquire and release down() and up(), and your e-mail is an example of this unhapiness.
Am I making it up that you are unhappy with usurping the down() and up() names for mutex use? If this is you being happy, I'd hate to see unhappy.
> So tell me, what do you think about your own arguments in that light?
I think they're still completely valid. Nothing you've said even seems to address the points I've raised.
>> 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.
As I said, as long as the -rt patch was not in the main tree, taking advantage of the fact that 95% of the down() and up() callers just want a mutex was a sensible implementation tradeoff. For merging it into the tree, it's ugly, and people don't like that. The -rt folks have gotten used to their naming perversions and so don't feel as much repugnance.
> 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.
Agreed. A mutex that's slower than a counting semaphore needs to be dragged out behind the wodshed and strangled. If you can't do any better, it can just *be* a counting semaphore.
> 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.
There haven't been problems with the semaphore *implementation*, but people screw up and deadlock themselves often enough. I sure remember double-acquire lockups. Forgive me if I don't grep the archives, but I remember people showing code paths that led to them.
Admittedly, lock *ordering* problems are the most common deadlock situtation but hey, guess what! Priority inheritance code can be extended to notice that, too. (There's a performance hit, so it'd be a debug option.)
But all of this requires that a lock have an identifiable owner, which is something hat a mutex has and a semaphore fundamentally doesn't.
> 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.
If you want to argue about names, go discuss gay marriage.
I don't care what it's *called*. I care that we have stronger conditions that we can test for correctness.
> So go away. > > Come back if you have pondered, and accepted reality, and perhaps have an > acceptable patch that introduces a separate data structure.
Ha! I still say you're wrong, and I'm not going to fold over an obvious technical point just because of flaming.
Are we having some communication problems? I find it hard to believe that you're actually this *stupid*, but we might not be talking about the same thing.
I took your posting to say that
a) Using the names "struct semaphore", "up()" and "down()" for a mutex is monumentally brain-dead. I'm not arguing, although I understand the pragmatic reasons for the original abuse of notation.
b) There is no need for a mutex implementation, because a semaphore can do anything that a mutex can. Here, I absolutely disagree. There are things you can do with a mutex that you CANNOT do with a general semaphore, because a mutex has stronger invariants.
A counting semaphore can do MOST of what a mutex does, and is demonstrably close enough for a lot of uses.
> 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.
Given that 95% of callers are using it as mutex, you're making this 20 times more work than necessary. Convert 'em all and change the 5% that need the counting back.
> And hell yes, performance does matter.
I'm not arguing, but this seems to be at odds with your earlier statement: >>> Dammit, unless the pure mutex has a _huge_ performance advantage on major >>> architectures, we're not changing it.
There is obviously no reason to accept a performance *decrease*, but any potential performance *increase* is unimportant and incidental.
Which is exactly what I said: >> Indeed, unless there's a performance advantage to a counting semaphore, >> you should use a mutex! - 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/
| |