Philip K.F. Hölzenspies wrote:
I ran face first into an assumption I had made on MVar operations (in Control.Concurrent); I had assumed there to be an atomic read (i.e. non-destructive read, as opposed to destructive consume/take). The following program illustrates what I had in mind.
testAtomic :: IO () testAtomic = do var <- newMVar 0 putStrLn("Fork") forkIO (putMVar var 1 >> putStrLn "X") yield r1 <- readMVar var putStrLn("1") r2 <- takeMVar var putStrLn("2") r3 <- takeMVar var putStrLn("Result: " ++ show [r1,r2,r3])
If readMVar had been atomic, the result would be program termination with a result of [0,0,1] being output. However, readMVar simply combines takeMVar and putMVar, so the reading of r1 blocks after the takeMVar, because upon taking the MVar, the blocked thread wakes up, puts 1 in var and prints X. readMVar does not terminate for r1 (i.e. "1" is never printed).
I have now implemented my variable as a pair of MVars, one of which serves as a lock on the other. Both for performance reasons and for deadlock analysis, I would really like an atomic read on MVars, though. Does it exist? If not, why not?
It would be slightly annoying to implement, because it needs changes in putMVar too: if there are blocked readMVars, then putMVar would have to wake them all up. Right now an MVar can only have one type of blocked thread attached to it at a time, either takeMVars or putMVars, and putMVar only has to wake a single thread. Perhaps you should be using STM? I suppose the answer to "why doesn't atomic readMVar exist" is that MVar is intended to be a basic low-level synchronisation abstraction, on which you can build larger abstractions (which you have indeed done). On other other hand, we're always interested in getting good value out of the building blocks, so when there are useful operations we can add without adding distributed complexity, that's often a good idea. I'm not sure that atomic readMVar falls into this category, though. Cheers, Simon