Memory fence around stg_atomicModifyMutVarzh

[Ryan Yates]

Hi Michael,

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:

http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/

Ryan

On Wed, Oct 21, 2015 at 1:58 PM, Michael Walker <mike at barrucadu.co.uk>
wrote:

> > >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)
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151021/2dae6871/attachment.html>