After reading some of the background and seeing this, +1 (Frankly, I
didn't even know before this that readMVar had the race condition you
described, and from my point of view, it should simply be fixed!)
Also: If you add a small release note blurb for the changes `base`,
that would be wonderful too. :)
On Wed, Jul 10, 2013 at 4:20 AM, 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
-- Regards, Austin - PGP: 4096R/0x91384671