Memory fence around stg_atomicModifyMutVarzh
mike at barrucadu.co.uk
Wed Oct 21 17:58:50 UTC 2015
> >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
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
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?
Michael Walker (http://www.barrucadu.co.uk)
More information about the ghc-devs