Proposal: replace readMVar with atomicReadMVar, breaking BC

[Edward Z. Yang]

Where do these release notes live?

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