<br><br><div class="gmail_quote">On Fri, Dec 24, 2010 at 5:32 PM, Edward Z. Yang <span dir="ltr"><<a href="mailto:ezyang@mit.edu">ezyang@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Merry Christmas all!<br>
<br>
Is it just me, or does the Control.Concurrent.MVar documentation seem a bit<br>
misleading? In particular, we should explicitly note the race conditions<br>
for not just swapMVar but also readMVar, withMVar, modifyMVar_ and modifyMVar,<br>
and clarify that the safety guarantees of the latter three pertain to their<br>
handling of asynchronous exceptions.<br>
<br>
It might also be good to tell people that if they need race-free operations<br>
of this style, STM is a good alternative to look at, even if only one variable<br>
is being synchronized over.<br></blockquote><div><br></div><div>This reminds me, I recall someone showing me some runtimes that implied for nearly all programs TVars had better performance than MVars. I can't find those results on google.</div>
<div><br></div><div>I did find this thread:</div><div><a href="http://www.mail-archive.com/haskell-cafe@haskell.org/msg50734.html">http://www.mail-archive.com/haskell-cafe@haskell.org/msg50734.html</a></div><div><br></div>
<div>The links in Don's mail are broken. It seems that Simon Marlow's paper directory didn't survive the server transition:</div><div><a href="http://www.haskell.org/~simonmar/papers/">http://www.haskell.org/~simonmar/papers/</a></div>
<div><br></div><div>Jason</div></div>