Proposal: replace readMVar with atomicReadMVar, breaking BC

[Edward Z. Yang]

Clever me, I already described this behavior:

-- |Atomically read the contents of an 'MVar'.  If the 'MVar' is
-- currently empty, 'atomicReadMVar' will wait until its full.
-- 'atomicReadMVar' is guaranteed to receive the next 'putMVar'.
--
-- 'atomicReadMVar' is multiple-wakeup, so when multiple readers are
-- blocked on an 'MVar', all of them are woken up at the same time.

Emphasis on "guaranteed to receive the next 'putMVar' :)

Edward

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