Re: [Haskell-cafe] Misleading MVar documentation

Mitar wrote:

Hi!

On Sat, Dec 25, 2010 at 11:58 AM, Edward Z. Yang wrote:

...

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

Yes, MVars are (bounded, 1 space long) queues with predictable behavior.

Maybe we should change documentation for swapMVar (and others) and replace notion of race condition with that it can block.

But this was not the issue this thread was about, namely: If readMVar (to pick one example) is applied to a full MVar with a pending putMVar, then readMVar will block *after* reading the value from the MVar, before being able to put it back. This is surprising, as it means that the value of the MVar can change during the execution of readMVar. (it will be changed back before readMVar completes but then the damage may already be done.) I think atomicity is the right concept here: All these operations consist of two separate steps (and can be interrupted in the middle) and this behaviour is observable if the MVar is not used in a single token mutex fashion, where either the MVar is full or there is exactly one thread owning the token. (Unlike simple mutexes, the MVar token can be labeled and re-labeled by the thread owning it.) Best regards, Bertram