Is there a reason why as I programmer I should prefer the non-FIFO
semantics, or is it implemented that way for efficiency?
Tom
El Jul 10, 2013, a las 5:20, "Edward Z. Yang"
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