<div dir="ltr">+1 from me. I don't think anyone really wants the current readMVar semantics anyway, and if somebody really does they can define their own non-atomic readMVar. Thanks for working on this!</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 4:38 AM, Edward Z. Yang <span dir="ltr"><<a href="mailto:ezyang@mit.edu" target="_blank">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">
Oh, found it.<br>
<div class="im HOEnZb"><br>
Excerpts from Austin Seipp's message of Wed Jul 10 12:28:48 -0700 2013:<br>
</div><div class="HOEnZb"><div class="h5">> After reading some of the background and seeing this, +1 (Frankly, I<br>
> didn't even know before this that readMVar had the race condition you<br>
> described, and from my point of view, it should simply be fixed!)<br>
><br>
> Also: If you add a small release note blurb for the changes `base`,<br>
> that would be wonderful too. :)<br>
><br>
> On Wed, Jul 10, 2013 at 4:20 AM, Edward Z. Yang <<a href="mailto:ezyang@mit.edu">ezyang@mit.edu</a>> wrote:<br>
> > GHC HEAD recently got a new primitive: atomicReadMVar#, which allows you<br>
> > to read MVars without first taking and then putting back (removing a<br>
> > nasty race where readMVar only works properly when there are no waiting<br>
> > putters).<br>
> ><br>
> > atomicReadMVar behaves differently from readMVar. The key<br>
> > differences are:<br>
> ><br>
> > - An atomicReadMVar op never causes an MVar to become "empty" at any point.<br>
> > This means less programs deadlock now.<br>
> ><br>
> > - An blocked atomicReadMVar is always served by the *first* putMVar<br>
> > to arrive (it cuts to the head of the queue), whereas readMVar<br>
> > obeyed the FIFO ordering. This means this program behaves differently:<br>
> ><br>
> > m <- newEmptyMVar<br>
> > forkIO $ takeMVar m<br>
> > threadDelay 100<br>
> > forkIO $ print =<< readMVar m {- atomicReadMVar m -}<br>
> > threadDelay 100<br>
> > putMVar m 1<br>
> > putMVar m 2<br>
> > -- readMVar: outputs 2<br>
> > -- atomicReadMVar: outputs 1<br>
> ><br>
> > It actually would not be too difficult to add support for atomicReadMVar<br>
> > which *does* respect the FIFO ordering but I don't have a sense when<br>
> > that would be useful.<br>
> ><br>
> > The general feeling Simon and I have is that everyone really wanted<br>
> > to make believe readMVar was atomicReadMVar, and so maybe we should<br>
> > break BC and make readMVar do the right thing. But it is probably<br>
> > worth some discussion, and I entreat you to think about the second<br>
> > point more carefully.<br>
> ><br>
> > Thanks,<br>
> > Edward<br>
> ><br>
> > _______________________________________________<br>
> > Libraries mailing list<br>
> > <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> > <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
><br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>