[Haskell-cafe] Misleading MVar documentation

[Edward Z. Yang]

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:
> 
> http://hackage.haskell.org/trac/ghc/ticket/4535

They seem like good suggestions.

Cheers,
Edward