<div dir="ltr">Hi Ben,<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 2, 2016 at 9:54 AM, Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
While we are in the process of revising the Mutex infrastructure [1]<br>
to use dedicated primitives rather than rely on counting via a<br>
semaphore, I want to raise the question of simple versus recursive<br>
mutexes.<br>
<br>
This isn't something I know much about, except that some people<br>
strongly believe recursive mutexes are evil, including David Butenhof<br>
who apparently was the guy who added recursive mutexes to POSIX "on a<br>
dare [...] but nobody was supposed to use recursive mutexes." [1].<br>
<br>
There are two interesting discussion on stockoverflow [2][3]. But btw<br>
I disagree with Tall Jeff [3] says "The difference between a recursive<br>
and non-recursive mutex has to do with ownership. " I think he<br>
confuses a simple-mutex and binary-semaphore, as do a some commenters.<br>
<br>
"Prefer Simple Mutex Over Recursive Mutex" [4] demonstrates some<br>
performance considerations and advises "a recursive mutex is dangerous<br>
because you lose sense of locking scope. It costs more than a simple<br>
mutex."<br>
<br>
"Recursive Locks Will Kill You!" [5] provides some thread safety guidelines.<br>
<br>
Finally, there is a paper "Ad Hoc Synchronization Considered harmful"<br>
[6], which I haven't read yet since I wanted to get this post out<br>
before heading to bed, but I hope to tomorrow.<br>
<br>
<br>
[1] <a href="http://www.zaval.org/resources/library/butenhof1.html" rel="noreferrer" target="_blank">http://www.zaval.org/resources/library/butenhof1.html</a><br>
[2] <a href="http://stackoverflow.com/questions/2415082/when-to-use-recursive-mutex" rel="noreferrer" target="_blank">http://stackoverflow.com/questions/2415082/when-to-use-recursive-mutex</a><br>
[3] <a href="http://stackoverflow.com/questions/187761/recursive-lock-mutex-vs-non-recursive-lock-mutex" rel="noreferrer" target="_blank">http://stackoverflow.com/questions/187761/recursive-lock-mutex-vs-non-recursive-lock-mutex</a><br>
[4] <a href="http://askldjd.com/2009/10/26/prefer-simple-mutex-over-recursive-mutex/" rel="noreferrer" target="_blank">http://askldjd.com/2009/10/26/prefer-simple-mutex-over-recursive-mutex/</a><br>
[5] <a href="http://www.fieryrobot.com/blog/2008/10/14/recursive-locks-will-kill-you/" rel="noreferrer" target="_blank">http://www.fieryrobot.com/blog/2008/10/14/recursive-locks-will-kill-you/</a><br>
[6] <a href="https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Xiong.pdf" rel="noreferrer" target="_blank">https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Xiong.pdf</a><br>
<br>
<br>
So our existing Mutex implementation happens to be recursive, and I'm<br>
not suggesting we change that. However if we should consider *not*<br>
baking the *assumption* of recursion into the primitives, so the same<br>
primitives could *also* be used for a SimpleMutex class. The logic to<br>
provide recursion for Mutex is only [ owner = activeProcess ] which is<br>
easily done in-image.<br>
<br>
So I propose introducing aquire/release primitives based off the<br>
existing critical section primitives with the recursion removed.<br></blockquote><div><br></div><div>We have two sets of primitives, the queueing semaphore ones, signal and wait, #85 & #86, which are not recursive, and new ones, #185, #186 & #187 that support ownership, and hence support recursion. It makes no sense to remove the recursion support. That's what the primitives are for, to provide ownership support as efficiently as possible. Please don't be led by the problems others may have in other systems, and instead be led by how we're doing. Squeak and Pharo (and Smalltalk) have had recursive owned critical sections for decades and no one (e.g. from demanding industrial control applications) has complained that these recursive critical sections are problematic. Remember we have closures and hence ensure: and good unwinding support. The new primitives give us a streamlined and hack-free implementation which doesn't depend on the niceties of what are suspension points as do the pre-primitive implementations. So I see no rationale for gelding these primitives.</div><div><br></div><div>Show me a paper on a Smalltalk app that says "recursive locks will kill you" and I'll reconsider, but in thirty years I've not seen a complaint. The complaints I have seen are</div><div><br></div><div>- queueing Semaphores should or should not be priority queues, depending on requirements. In VW #85 & #86 were changed so that Semaphore is a priority queue. This has been good for some folks but bad for others. One should have the choice, but the current Squeak/Pharo/Smalltalk-80 default that they are /not/ priority queues is the right default</div><div><br></div><div>- we suffer from deadlock due to priority inversion. A high-priority process spinning trying to gain access to a lock held by a low-priority process can shut out the low-priority process from releasing its lock. This is minimised by the new recursive lock primitives, but may still be a possibility. We should work on creating test cases. Positively the test cases that Andreas developed for me at Qwaq when I developed the recursive locking primitives no longer fail. I've not had time to investigate.</div><div><br></div><div>- preempting a lower-priority process by a higher-priority process causes the preempted process to yield to others at the same priority. This is a bug which has been fixed in VW and in Cog. It is an option in Cog but it should be enabled. See SmalltalkImage>>processPreemptionYields. Smalltalk processPreemptionYields should answer false.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">cheers -ben<br>
</blockquote></div><br>HTH<br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>