Excerpts from Mitar's message of Fri Dec 24 23:18:43 -0500 2010:
I am not sure if this are really race conditions? The point is that readMVar, withMVar and others do not return until they can return the value back and after that the value is the same as it was at the beginning of the call. So if somebody manages to put the value in then those functions wait that the value is removed.
Race condition would mean for me that some other thread could corrupt the data. This is not the case here.
I think you're right. A further comment is that you don't really need stringent timing conditions (which is the only thing I think of when I hear "race") to see another thread "grab" the mvar underneath you: a script as simple as this sees this behavior due to MVar's fairness properties: import Control.Concurrent.MVar import Control.Concurrent main = do r <- newMVar 1 forkIO $ do putMVar r 2 print "Executed" threadDelay 200 readMVar r print "Not executed"
So I would argue that it would be better to write that those function can block. Not that there are race-conditions. Race-conditions (for me) imply that invariants can change based on some other thread, here they hold, when/if the function returns.
Sure.
This is why I proposed tryReadMVar and tryModifyMVar here:
They seem like good suggestions. Cheers, Edward