Hi John,

My understanding is that GHC does do reordering of memory operations, in the CmmSink pass (http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/src/CmmSink.html, http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/).  In particular ghc may currently reorder loads, although it doesn't seem to reorder stores (at this time).  And ghc *currently* only performs these reorderings in limited cases.

Thanks!  That's a great summary by ezyang and I hadn't yet read it.

I have to confess that I don't understand what you mean by suggesting we should implement these primops without having an underlying memory model. 

Oh, no, I think we should work on getting as close as possible to said memory model.  But given how much work it's been for other languages I hope we can pipeline some of the implementation tasks, at the same time as that is going on.  For 
example, we've got one GSOC working on a concurrent data structure, and it would be great if they could have a GHC branch to test inlined primops, even if there is much more work to do to verify the safety of that prototype before it makes it to the master branch.
 (There's also the social question of getting someone with enough time to do this memory model -- or port it from other languages.  Suggestions?)
 
What does atomicReadIntArray# mean if there's no memory model in which its defined?  How can you be sure that other ghc hackers won't break some assumptions that the implementations rely upon, if they don't have a memory model to describe how operations should behave?  This is strongly related to the TODO: in Johan's proposal: just because that may be true now (I don't know if it is!) doesn't mean it will remain so in the future.

I totally agree.  I'm just not sure where we should go with it.  
    I think as a practical matter we need some kind of memory model fuzz tester for GHC, since we certainly won't have formal verification throughout the whole compiler.  There's been some neat work on this in the memory models community, it seems.  It sounds like Jan-Willem also suggests that there should be invasive changes made to the compiler to reify the memory model as a DAG of dependencies on the individual operations.

I guess the concrete choice for Johan's proposed changes is to figure out if its possible to quickly hack the relevant CMM passes that might reorder (to be primop aware), rather than make the more general improvement that Jan-Willem suggested in the comments on ezyang's post.

Of course, given the limited number of GHC hackers, everything may work out fine in the end.  It just seems to me that it would be more sensible to define the semantics first and build the primops around them, rather than primops first and semantics later.

I think it's a bit of a chicken and egg, because we need to get interesting enough data structures and libraries to make someone care enough to do this work ;-).

I think we need a collaboration with someone who does memory model stuff for a living if we could get them interested or make this into "research" somehow.