CINXE.COM

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>LKML: linux@horizon ...: Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation</title><link href="/css/message.css" rel="stylesheet" type="text/css" /><link href="/css/wrap.css" rel="alternate stylesheet" type="text/css" title="wrap" /><link href="/css/nowrap.css" rel="stylesheet" type="text/css" title="nowrap" /><link href="/favicon.ico" rel="shortcut icon" /><script src="/js/simple-calendar.js" type="text/javascript"></script><script src="/js/styleswitcher.js" type="text/javascript"></script><link rel="alternate" type="application/rss+xml" title="lkml.org : last 100 messages" href="/rss.php" /><link rel="alternate" type="application/rss+xml" title="lkml.org : last messages by 	linux@horizon ..." href="/groupie.php?aid=25483" /><script> var _paq = window._paq = window._paq || []; /* tracker methods like "setCustomDimension" should be called before "trackPageView" */ _paq.push(["setDoNotTrack", true]); _paq.push(["disableCookies"]); _paq.push(['trackPageView']); _paq.push(['enableLinkTracking']); (function() { var u="//m.lkml.org/"; _paq.push(['setTrackerUrl', u+'matomo.php']); _paq.push(['setSiteId', '1']); var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s); })(); </script></head><body onload="es.jasper.simpleCalendar.init();" itemscope="itemscope" itemtype="http://schema.org/BlogPosting"><table border="0" cellpadding="0" cellspacing="0"><tr><td width="180" align="center"><a href="/"><img style="border:0;width:135px;height:32px" src="/images/toprowlk.gif" alt="lkml.org" /></a></td><td width="32">聽</td><td class="nb"><div><a class="nb" href="/lkml"> [lkml]</a> 聽 <a class="nb" href="/lkml/2005"> [2005]</a> 聽 <a class="nb" href="/lkml/2005/12"> [Dec]</a> 聽 <a class="nb" href="/lkml/2005/12/15"> [15]</a> 聽 <a class="nb" href="/lkml/last100"> [last100]</a> 聽 <a href="/rss.php"><img src="/images/rss-or.gif" border="0" alt="RSS Feed" /></a></div><div>Views: <a href="#" class="nowrap" onclick="setActiveStyleSheet('wrap');return false;">[wrap]</a><a href="#" class="wrap" onclick="setActiveStyleSheet('nowrap');return false;">[no wrap]</a> 聽 <a class="nb" href="/lkml/mheaders/2005/12/15/274" onclick="this.href='/lkml/headers'+'/2005/12/15/274';">[headers]</a>聽 <a href="/lkml/bounce/2005/12/15/274">[forward]</a>聽 </div></td><td width="32">聽</td></tr><tr><td valign="top"><div class="es-jasper-simpleCalendar" baseurl="/lkml/"></div><div class="threadlist">Messages in this thread</div><ul class="threadlist"><li class="root"><a href="/lkml/2005/12/15/149">First message in thread</a></li><li><a href="/lkml/2005/12/15/149"> linux@horizon ...</a><ul><li><a href="/lkml/2005/12/15/201">Linus Torvalds</a><ul><li><a href="/lkml/2005/12/15/216">Erik Mouw</a><ul><li><a href="/lkml/2005/12/15/224">(Dick Streefland)</a></li><li><a href="/lkml/2005/12/16/61">Erik Mouw</a><ul><li><a href="/lkml/2005/12/17/22">Sander</a></li></ul></li></ul></li><li><a href="/lkml/2005/12/15/269">Nikita Danilov</a></li><li class="origin"><a href="/lkml/2005/12/15/286"> linux@horizon ...</a><ul><li><a href="/lkml/2005/12/15/286">Linus Torvalds</a><ul><li><a href="/lkml/2005/12/15/422"> linux@horizon ...</a></li></ul></li><li><a href="/lkml/2005/12/15/315">Steven Rostedt</a></li></ul></li><li><a href="/lkml/2005/12/15/304">Steven Rostedt</a></li></ul></li></ul></li></ul></td><td width="32" rowspan="2" class="c" valign="top"><img src="/images/icornerl.gif" width="32" height="32" alt="/" /></td><td class="c" rowspan="2" valign="top" style="padding-top: 1em"><table><tr><td><table><tr><td class="lp">Date</td><td class="rp" itemprop="datePublished">15 Dec 2005 14:09:37 -0500</td></tr><tr><td class="lp">From</td><td class="rp" itemprop="author"> linux@horizon ...</td></tr><tr><td class="lp">Subject</td><td class="rp" itemprop="name">Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation</td></tr></table></td><td></td></tr></table><pre itemprop="articleBody">> 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 <a href="http://vger.kernel.org/majordomo-info.html">http://vger.kernel.org/majordomo-info.html</a> Please read the FAQ at <a href="http://www.tux.org/lkml/">http://www.tux.org/lkml/</a> </pre></td><td width="32" rowspan="2" class="c" valign="top"><img src="/images/icornerr.gif" width="32" height="32" alt="\" /></td></tr><tr><td align="right" valign="bottom"> 聽 </td></tr><tr><td align="right" valign="bottom">聽</td><td class="c" valign="bottom" style="padding-bottom: 0px"><img src="/images/bcornerl.gif" width="32" height="32" alt="\" /></td><td class="c">聽</td><td class="c" valign="bottom" style="padding-bottom: 0px"><img src="/images/bcornerr.gif" width="32" height="32" alt="/" /></td></tr><tr><td align="right" valign="top" colspan="2"> 聽 </td><td class="lm">Last update: 2005-12-15 20:12 聽聽 [from the cache] 漏2003-2020 <a href="http://blog.jasper.es/">Jasper Spaans</a>|hosted at <a href="https://www.digitalocean.com/?refcode=9a8e99d24cf9">Digital Ocean</a> and my Meterkast|<a href="http://blog.jasper.es/categories.html#lkml-ref">Read the blog</a></td><td>聽</td></tr></table><script language="javascript" src="/js/styleswitcher.js" type="text/javascript"></script></body></html>