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@haskell.org [mailto:libraries- | bounces@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@haskell.org | http://www.haskell.org/mailman/listinfo/libraries