Clever me, I already described this behavior: -- |Atomically read the contents of an 'MVar'. If the 'MVar' is -- currently empty, 'atomicReadMVar' will wait until its full. -- 'atomicReadMVar' is guaranteed to receive the next 'putMVar'. -- -- 'atomicReadMVar' is multiple-wakeup, so when multiple readers are -- blocked on an 'MVar', all of them are woken up at the same time. Emphasis on "guaranteed to receive the next 'putMVar' :) Edward Excerpts from Edward Z. Yang's message of Wed Jul 10 10:08:17 -0700 2013:

I only realized that the ordering semantics were different when I was writing this email. I'll go add them to the Haddock docs.

Excerpts from Simon Peyton-Jones's message of Wed Jul 10 03:47:27 -0700 2013:

...

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

Excerpts from Tom Murphy's message of Wed Jul 10 05:45:36 -0700 2013:

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

Timely delivery of reads. Ordinary takeMVar is FIFO for fairness reasons: so long as an MVar is not held indefinitely, all takeMVars will be serviced. For reads, we can service them immediately without worrying about fairness, since they don't block anyone. It is literally trivial to do either FIFO and non-FIFO implementation wise. Edward

+1 for changing readMVar to be atomic, but we should probably mention the change in the doc for readMVar, something like the following (perhaps in fewer words): -- | ... -- -- /Compatibility note:/ prior to base 4.7, 'readMVar' was a combination -- of 'takeMVar' and 'putMVar', resulting in two drawbacks: -- -- * 'readMVar' was not atomic in the presence of multiple producers. -- Between taking the value and putting it back, another thread -- calling 'putMVar' could win, causing 'readMVar' to block after -- retrieving a value. -- -- * 'readMVar' was not multiple wakeup, meaning each consumer had to -- wake up the next.

Where do these release notes live? Excerpts from Austin Seipp's message of Wed Jul 10 12:28:48 -0700 2013:

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 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

+1 from me. I don't think anyone really wants the current readMVar semantics anyway, and if somebody really does they can define their own non-atomic readMVar. Thanks for working on this! On Thu, Jul 11, 2013 at 4:38 AM, Edward Z. Yang wrote:

Oh, found it.

Excerpts from Austin Seipp's message of Wed Jul 10 12:28:48 -0700 2013:

...

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 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

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