From: linux@horizon.com
To: linux@horizon.com, torvalds@osdl.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
Date: 15 Dec 2005 14:09:37 -0500 [thread overview]
Message-ID: <20051215190937.5869.qmail@science.horizon.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0512150752240.3292@g5.osdl.org>
> 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!
next prev parent reply other threads:[~2005-12-15 19:09 UTC|newest]
Thread overview: 227+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-15 13:58 [PATCH 1/19] MUTEX: Introduce simple mutex implementation linux
2005-12-15 16:15 ` Linus Torvalds
2005-12-15 16:52 ` Erik Mouw
2005-12-15 17:23 ` Dick Streefland
2005-12-16 12:17 ` Erik Mouw
2005-12-17 10:59 ` Sander
2005-12-17 14:14 ` Douglas McNaught
2005-12-17 15:09 ` Sander
2005-12-19 10:44 ` Erik Mouw
2005-12-15 19:02 ` Nikita Danilov
2005-12-15 19:09 ` linux [this message]
2005-12-15 19:52 ` Linus Torvalds
2005-12-16 1:33 ` linux
2005-12-15 21:18 ` Steven Rostedt
2005-12-15 20:52 ` Steven Rostedt
-- strict thread matches above, loose matches on Subject: below --
2005-12-16 12:49 linux
2005-12-16 15:24 ` David Howells
2005-12-16 18:03 ` linux
2005-12-15 17:45 Luck, Tony
2005-12-15 18:00 ` David Howells
2005-12-15 18:48 ` James Bottomley
2005-12-15 20:38 ` Jeff Dike
2005-12-15 23:45 ` Stephen Rothwell
2005-12-12 23:45 David Howells
2005-12-13 0:13 ` Nick Piggin
2005-12-13 0:19 ` Nick Piggin
2005-12-13 0:19 ` Andrew Morton
2005-12-13 7:54 ` Ingo Molnar
2005-12-13 7:58 ` Andi Kleen
2005-12-13 8:42 ` Andrew Morton
2005-12-13 8:49 ` Andi Kleen
2005-12-13 9:01 ` Andrew Morton
2005-12-13 9:02 ` Andrew Morton
2005-12-13 10:07 ` Jakub Jelinek
2005-12-13 10:11 ` Andi Kleen
2005-12-13 10:15 ` Jakub Jelinek
2005-12-13 10:25 ` Andrew Morton
2005-12-14 10:46 ` Russell King
2005-12-13 9:05 ` Andi Kleen
2005-12-13 9:15 ` Andrew Morton
2005-12-13 9:24 ` Andi Kleen
2005-12-13 9:44 ` Andrew Morton
2005-12-13 9:49 ` Andi Kleen
2005-12-13 10:28 ` Andreas Schwab
2005-12-13 10:30 ` Andi Kleen
2005-12-13 12:33 ` Matthew Wilcox
2005-12-13 22:18 ` Adrian Bunk
2005-12-13 22:25 ` Andi Kleen
2005-12-13 22:32 ` Adrian Bunk
2005-12-13 9:11 ` Ingo Molnar
2005-12-13 9:04 ` Christoph Hellwig
2005-12-13 9:13 ` Ingo Molnar
2005-12-13 10:11 ` Jakub Jelinek
2005-12-13 10:19 ` Christoph Hellwig
2005-12-13 10:27 ` Ingo Molnar
2005-12-15 4:53 ` Miles Bader
2005-12-15 5:05 ` Nick Piggin
2005-12-13 9:09 ` Ingo Molnar
2005-12-13 9:21 ` Andi Kleen
2005-12-13 16:16 ` Linus Torvalds
2005-12-13 9:03 ` Christoph Hellwig
2005-12-13 9:14 ` Andrew Morton
2005-12-13 9:21 ` Christoph Hellwig
2005-12-13 8:00 ` Arjan van de Ven
2005-12-13 9:03 ` Ingo Molnar
2005-12-13 9:09 ` Andi Kleen
2005-12-13 9:34 ` Ingo Molnar
2005-12-13 14:33 ` Mark Lord
2005-12-13 14:45 ` Arjan van de Ven
2005-12-13 9:37 ` Ingo Molnar
2005-12-13 9:19 ` Arjan van de Ven
2005-12-13 9:02 ` Christoph Hellwig
2005-12-13 9:39 ` Ingo Molnar
2005-12-13 10:00 ` Ingo Molnar
2005-12-13 17:40 ` Paul Jackson
2005-12-13 18:34 ` David Howells
2005-12-13 22:31 ` Paul Jackson
2005-12-14 11:02 ` David Howells
2005-12-14 11:12 ` David Howells
2005-12-14 11:18 ` Alan Cox
2005-12-14 12:35 ` David Howells
2005-12-14 13:58 ` Thomas Gleixner
2005-12-14 23:40 ` Mark Lord
2005-12-14 23:54 ` Andrew Morton
2005-12-15 13:41 ` Nikita Danilov
2005-12-15 14:56 ` Alan Cox
2005-12-15 15:52 ` Nikita Danilov
2005-12-15 16:50 ` Christopher Friesen
2005-12-15 20:53 ` Steven Rostedt
2005-12-15 15:55 ` David Howells
2005-12-15 16:22 ` linux-os (Dick Johnson)
2005-12-15 16:28 ` Linus Torvalds
2005-12-15 17:04 ` Thomas Gleixner
2005-12-15 17:09 ` Paul Jackson
2005-12-15 17:17 ` David Howells
2005-12-15 16:51 ` David Howells
2005-12-15 16:56 ` Paul Jackson
2005-12-15 17:28 ` David Howells
2005-12-15 17:48 ` Linus Torvalds
2005-12-15 18:20 ` Nikita Danilov
2005-12-15 20:58 ` Steven Rostedt
2005-12-15 19:21 ` Andrew Morton
2005-12-15 19:38 ` Linus Torvalds
2005-12-15 20:28 ` Steven Rostedt
2005-12-15 20:32 ` Geert Uytterhoeven
2005-12-16 21:41 ` Thomas Gleixner
2005-12-16 21:41 ` Linus Torvalds
2005-12-16 22:06 ` Thomas Gleixner
2005-12-16 22:19 ` Linus Torvalds
2005-12-16 22:32 ` Steven Rostedt
2005-12-16 22:42 ` Thomas Gleixner
2005-12-16 22:41 ` Linus Torvalds
2005-12-16 22:49 ` Steven Rostedt
2005-12-16 23:29 ` Thomas Gleixner
2005-12-17 0:29 ` Joe Korty
2005-12-17 1:00 ` Linus Torvalds
2005-12-17 3:13 ` Steven Rostedt
2005-12-17 7:34 ` Linus Torvalds
2005-12-17 23:43 ` Matthew Wilcox
2005-12-18 0:05 ` Lee Revell
2005-12-18 0:21 ` Matthew Wilcox
2005-12-18 1:25 ` Lee Revell
2005-12-22 12:27 ` Bill Huey
2005-12-19 16:08 ` Ingo Molnar
2005-12-22 12:40 ` Bill Huey
2005-12-22 12:45 ` Bill Huey
2005-12-19 23:46 ` Keith Owens
2005-12-15 14:41 ` Steven Rostedt
2005-12-14 23:57 ` Thomas Gleixner
2005-12-14 23:57 ` Mark Lord
2005-12-15 0:10 ` Thomas Gleixner
2005-12-15 2:46 ` Linus Torvalds
2005-12-15 15:53 ` David Howells
2005-12-15 15:37 ` David Howells
2005-12-15 19:28 ` Andrew Morton
2005-12-15 20:18 ` Andrew Morton
2005-12-15 21:28 ` Steven Rostedt
2005-12-16 22:02 ` Thomas Gleixner
2005-12-16 10:45 ` David Howells
2005-12-13 9:55 ` Ingo Molnar
2005-12-13 0:30 ` Arnd Bergmann
2005-12-13 0:57 ` Daniel Walker
2005-12-13 3:23 ` Steven Rostedt
2005-12-13 2:57 ` Mark Lord
2005-12-13 3:17 ` Steven Rostedt
2005-12-13 9:06 ` Christoph Hellwig
2005-12-13 9:54 ` David Howells
2005-12-13 10:13 ` Ingo Molnar
2005-12-13 10:34 ` Ingo Molnar
2005-12-13 10:37 ` Ingo Molnar
2005-12-13 12:47 ` Oliver Neukum
2005-12-13 13:09 ` Alan Cox
2005-12-13 13:13 ` Matthew Wilcox
2005-12-13 14:04 ` Alan Cox
2005-12-13 13:24 ` Oliver Neukum
2005-12-14 1:00 ` Nick Piggin
2005-12-14 10:54 ` David Howells
2005-12-14 11:17 ` Nick Piggin
2005-12-14 11:46 ` David Howells
2005-12-14 21:23 ` Nick Piggin
2005-12-16 12:00 ` David Howells
2005-12-16 13:16 ` Nick Piggin
2005-12-16 15:53 ` David Howells
2005-12-16 23:41 ` Nick Piggin
2005-12-16 16:02 ` David Howells
2005-12-13 10:48 ` David Howells
2005-12-13 12:39 ` Matthew Wilcox
2005-12-13 10:54 ` Ingo Molnar
2005-12-13 11:23 ` David Howells
2005-12-13 11:24 ` David Howells
2005-12-13 13:45 ` Ingo Molnar
2005-12-13 11:34 ` David Howells
2005-12-13 13:05 ` Alan Cox
2005-12-13 13:15 ` Alan Cox
2005-12-13 23:21 ` Nikita Danilov
2005-12-13 13:32 ` David Howells
2005-12-13 14:00 ` Alan Cox
2005-12-13 14:35 ` Christopher Friesen
2005-12-13 14:44 ` Arjan van de Ven
2005-12-13 14:59 ` Christopher Friesen
2005-12-13 15:23 ` David Howells
2005-12-15 5:24 ` Miles Bader
2005-12-13 15:39 ` David Howells
2005-12-13 16:10 ` Alan Cox
2005-12-14 10:29 ` Arjan van de Ven
2005-12-14 11:03 ` Arjan van de Ven
2005-12-14 11:03 ` Alan Cox
2005-12-14 11:08 ` Arjan van de Ven
2005-12-14 11:24 ` Alan Cox
2005-12-14 11:35 ` Andrew Morton
2005-12-14 11:44 ` Arjan van de Ven
2005-12-14 11:52 ` Andi Kleen
2005-12-14 11:55 ` Arjan van de Ven
2005-12-14 11:57 ` David Howells
2005-12-14 12:19 ` Jakub Jelinek
2005-12-16 1:54 ` Nick Piggin
2005-12-16 11:02 ` David Howells
2005-12-16 13:01 ` Nick Piggin
2005-12-16 13:21 ` Russell King
2005-12-16 13:41 ` Nick Piggin
2005-12-16 13:46 ` Linh Dang
2005-12-16 14:31 ` Russell King
2005-12-16 15:24 ` Linh Dang
2005-12-16 15:35 ` Nick Piggin
2005-12-16 15:40 ` Kyle Moffett
2005-12-16 15:49 ` Linh Dang
2005-12-16 15:46 ` David Howells
2005-12-16 15:58 ` Russell King
2005-12-17 15:57 ` Nikita Danilov
2005-12-16 16:28 ` Linus Torvalds
2005-12-16 11:30 ` David Howells
2005-12-16 16:33 ` Linus Torvalds
2005-12-16 22:23 ` David S. Miller
2005-12-16 22:38 ` Linus Torvalds
2005-12-16 22:53 ` David S. Miller
2005-12-17 0:41 ` Jesse Barnes
2005-12-17 7:10 ` David S. Miller
2005-12-17 7:40 ` Linus Torvalds
2005-12-17 17:22 ` Jesse Barnes
2005-12-17 17:19 ` Jesse Barnes
2005-12-17 22:38 ` Richard Henderson
2005-12-17 23:05 ` David S. Miller
2005-12-14 12:17 ` Christoph Hellwig
2005-12-14 11:42 ` Arjan van de Ven
2005-12-14 8:31 ` Ingo Molnar
2005-12-13 20:04 ` Steven Rostedt
2005-12-13 21:03 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051215190937.5869.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).