MVar semantics: proposal

[Simon Marlow]

Sequence points... yes, all seems reasonable to me.

On 31 March 2006 00:50, John Meacham wrote:

> We should drop atomicModifyIORef since we have MVars, for
> architectures 
> with only a test and set instruction and no atomic exchange,
> supporting atomicModifyIORef would entail the same overhead as MVars.

Slightly less overhead than an MVar, because you only need one
lock/release to implement atomicModifyIORef, but two lock/release
combinations are involved in an update of an MVar.

atomicModifyIORef would be a sequence point, BTW.  Semantically, think
of it as having a hidden MVar attached to the IORef:

  withMVar m $ \_ -> do
    x <- readIORef  r
    let (x',y) = f x
    writeIORef r x'
    return y

as long as you have some way to enforce exclusion with respect to other
atomicModifyIORef operations on a given IORef, you can implement it like
this.

> atomicModifyIORef also cannot (easily) be implemented on
> implementations 
> that use update-in-place rather than indirections for thunk updates.

I don't follow you - how would that make it harder?

Cheers,
	Simon