#15159: Expand compatibility note for readMVar -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the note reads

Compatibility note: Prior to base 4.7, readMVar was a combination of takeMVar and putMVar. This mean that in the presence of other threads attempting to putMVar, readMVar could block. Furthermore, readMVar would not receive the next putMVar if there was already a pending thread blocked on takeMVar. The old behavior can be recovered by [...]

I don't think this goes quite far enough. Consider the following scenario: {{{#!hs main = do mv <- newEmptyMVar forkIO $ putMVar mv "a" >> ... >> takeMVar mv >>= ... forkIO $ putMVar mv "b" >> ... >> takeMVar mv >>= ... ... readMVar mv }}} (assume none of the ...s touch `mv`) With the current implementation of `readMVar`, each child thread will put its value in the `MVar` and then take that same value out. They may do so in either order, and the order will determine what value the main thread reads. With the ''old'' implementation of `readMVar`, there are two additional (symmetrical) possibilities. In one, the first child puts `"a"`, the main thread takes `"a"`, the second child puts `"b"`, the first child takes `"b"`, the main thread puts `"a"`, and the second child takes `"a"`. So the old version of `readMVar` could make an interaction between other threads substantially less deterministic. I believe the note should probably reflect that. Its language also could really use some clarification in general. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15159 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler