<div dir="ltr">Hi Michael,<div><br></div><div>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:</div><div><br></div><div><a href="http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/">http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/</a><br></div><div><br></div><div>Ryan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 1:58 PM, Michael Walker <span dir="ltr"><<a href="mailto:mike@barrucadu.co.uk" target="_blank">mike@barrucadu.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> >I'm afraid I don't know off the top of my head but hopefully Simon<br>
> >Marlow will be able to shed some more light here.<br>
> ><br>
> >When he does it would be great if you could write a nice comment<br>
> >explaining this logic and either open a Phabricator Diff or send the<br>
> >text to me so I can merge it.<br>
><br>
> Here is the barrier:<br>
><br>
>     (h) = ccall cas(mv + SIZEOF_StgHeader + OFFSET_StgMutVar_var, x, y);<br>
><br>
> cas() is an external C function defined in includes/stg/SMP.h using inline<br>
> assembly.<br>
<br>
</span>Wow, I really did miss it. Thanks for pointing it out.<br>
<br>
I also have a question about the sort of relaxed behaviours permitted. The<br>
Data.IORef docs say:<br>
<br>
> The implementation is required to ensure that reordering of memory operations<br>
> cannot cause type-correct code to go wrong. In particular, when inspecting the<br>
> value read from an IORef, the memory writes that created that value must have<br>
> occurred from the point of view of the current thread.<br>
<br>
but I'm not sure that's enough. This also seems clearly wrong, but is permitted<br>
by that restriction:<br>
<br>
    λ> newIORef False >>= \ref -> writeIORef ref True >> readIORef ref<br>
    False<br>
<br>
Is there a write-up anywhere of the memory model the GHC primitives give rise<br>
to? Or is it just one of those cases where the code is the specification?<br>
<br>
Thanks<br>
<span class="im HOEnZb"><br>
--<br>
Michael Walker (<a href="http://www.barrucadu.co.uk" rel="noreferrer" target="_blank">http://www.barrucadu.co.uk</a>)<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>