[Haskell-cafe] Misleading MVar documentation
Edward Z. Yang
ezyang at MIT.EDU
Sat Dec 25 11:58:56 CET 2010
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
main = do
r <- newMVar 1
forkIO $ do
putMVar r 2
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.
> This is why I proposed tryReadMVar and tryModifyMVar here:
They seem like good suggestions.
More information about the Haskell-Cafe