Proposal: replace readMVar with atomicReadMVar, breaking BC

Austin Seipp aseipp at pobox.com
Wed Jul 10 21:28:48 CEST 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



-- 
Regards,
Austin - PGP: 4096R/0x91384671



More information about the Libraries mailing list