Re: Proposal: replace readMVar with atomicReadMVar, breaking BC

On 10/07/13 13:45, Tom Murphy wrote:

Is there a reason why as I programmer I should prefer the non-FIFO semantics, or is it implemented that way for efficiency?

You might prefer the FIFO semantics if you want to take advantage of the fact that the RTS implements a double-ended queue of threads in such a way that threads can be removed from the middle in O(1) time if they receive an exception from throwTo. However, the only person I know that does this sort of thing is Chris Kuklewicz, and I can never understand his code. :-) I expect the readMVar-jumps-to-the-front-of-the-queue semantics will be more useful in most cases. We could have both, but I doubt it's worth it. Cheers, Simon

Tom

El Jul 10, 2013, a las 5:20, "Edward Z. Yang" escribió:

...

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries