Proposal: replace readMVar with atomicReadMVar, breaking BC
Simon Peyton-Jones
simonpj at microsoft.com
Wed Jul 10 12:47:27 CEST 2013
Good! Are the new semantics clearly documented?
Simon
| -----Original Message-----
| From: libraries-bounces at haskell.org [mailto:libraries-
| bounces at 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 at haskell.org
| http://www.haskell.org/mailman/listinfo/libraries
More information about the Libraries
mailing list