MVar interface [was: Re: ForeignPtr-related signatures]

Simon Marlow simonmar at
Tue Nov 19 06:37:23 EST 2002

> The current `modifyMVar`, though "exception safe", is not 
> "atomic" in the
> same way that the proposed `atomicModifyMVar` would be.  Unless I
> misunderstand, during the execution of `modifyMVar`'s second 
> argument, the
> mvar is empty and could be filled by some other thread.  With
> `atomicModifyMVar`, the contents of the mvar are changed 
> atomically, based
> on the given (pure) function; no other thread can intervene.

This is true, but I've never come across an application for which
atomicModifyMVar is essential; the two main idioms for using MVars that
I know of are

 - each thread does take followed by put in strict sequence

 - the MVar is used as a 1-place channel, with some threads doing
   put and some (usually one) doing take.

So the fact that modifyMVar isn't atomic in the presence of another
thread doing a concurrent put doesn't usually matter, because there are
no such threads.  However, I agree that atomicModifyMVar does provide
functionality which doesn't currently exist.


More information about the FFI mailing list