Proposal: replace readMVar with atomicReadMVar, breaking BC

[Edward Kmett]

+1

I agree that changing this is more likely to give users the functionality
that they expected from the API in the first place.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130711/211b5aa8/attachment.htm>