Memory fence around stg_atomicModifyMutVarzh

[Michael Walker]

> >I'm afraid I don't know off the top of my head but hopefully Simon
> >Marlow will be able to shed some more light here.
> >
> >When he does it would be great if you could write a nice comment
> >explaining this logic and either open a Phabricator Diff or send the
> >text to me so I can merge it.
> 
> Here is the barrier:
> 
>     (h) = ccall cas(mv + SIZEOF_StgHeader + OFFSET_StgMutVar_var, x, y);
> 
> cas() is an external C function defined in includes/stg/SMP.h using inline
> assembly.

Wow, I really did miss it. Thanks for pointing it out.

I also have a question about the sort of relaxed behaviours permitted. The
Data.IORef docs say:

> The implementation is required to ensure that reordering of memory operations
> cannot cause type-correct code to go wrong. In particular, when inspecting the
> value read from an IORef, the memory writes that created that value must have
> occurred from the point of view of the current thread.

but I'm not sure that's enough. This also seems clearly wrong, but is permitted
by that restriction:

    λ> newIORef False >>= \ref -> writeIORef ref True >> readIORef ref
    False

Is there a write-up anywhere of the memory model the GHC primitives give rise
to? Or is it just one of those cases where the code is the specification?

Thanks

-- 
Michael Walker (http://www.barrucadu.co.uk)