> 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.
Cheers,
Simon
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
