Proposal: replace readMVar with atomicReadMVar, breaking BC

[Edward Z. Yang]

I only realized that the ordering semantics were different when I
was writing this email.  I'll go add them to the Haddock docs.

Excerpts from Simon Peyton-Jones's message of Wed Jul 10 03:47:27 -0700 2013:
> Good!  Are the new semantics clearly documented?
> 
> Simon
> 
> | -----Original Message-----
> | From: libraries-bounces at haskell.org [mailto:libraries-
> | bounces at haskell.org] On Behalf Of Edward Z. Yang
> | Sent: 10 July 2013 10:20
> | To: libraries
> | Subject: Proposal: replace readMVar with atomicReadMVar, breaking BC
> | 
> | 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