[Haskell-cafe] Misleading MVar documentation

[Bertram Felgenhauer]

Mitar wrote:
> Hi!
> 
> On Sat, Dec 25, 2010 at 11:58 AM, Edward Z. Yang <ezyang at mit.edu> 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