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