Proposal: replace readMVar with atomicReadMVar, breaking BC

[John Lato]

+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!


On Thu, Jul 11, 2013 at 4:38 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Oh, found it.
>
> 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
> >
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130711/a6dd6ad5/attachment.htm>