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