I agree that changing this is more likely to give users the functionality that they expected from the API in the first place.
On Wed, Jul 10, 2013 at 4:20 AM, Edward Z. Yang
<ezyang@mit.edu> wrote:
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