Proposal: replace readMVar with atomicReadMVar, breaking BC

[Edward Z. Yang]

OK, it looks like the consensus is to change the old readMVar.  I will
go and implement this.

Edward

Excerpts from Edward Z. Yang's message of Wed Jul 10 02:20:14 -0700 2013:
> 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
>