No atomic read on MVar?
marlowsd at gmail.com
Mon Nov 3 08:43:11 EST 2008
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
> forkIO (putMVar var 1 >> putStrLn "X")
> r1 <- readMVar var
> r2 <- takeMVar var
> 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.
More information about the Glasgow-haskell-users