Memory fence around stg_atomicModifyMutVarzh
fryguybob at gmail.com
Wed Oct 21 18:26:41 UTC 2015
I don't think you can take that paragraph as an exhaustive description of
what orderings are allowed. Edward Yang has a post about the current state
of GHC and memory models that I think is still how things are:
On Wed, Oct 21, 2015 at 1:58 PM, Michael Walker <mike at barrucadu.co.uk>
> > >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
> > 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
> > 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
> > 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
> 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
> to? Or is it just one of those cases where the code is the specification?
> Michael Walker (http://www.barrucadu.co.uk)
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs