Adding atomic primops

[Ryan Newton]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140505/2d55c618/attachment-0001.html>