Adding atomic primops

Mon May 5 06:17:41 UTC 2014

Hi Ryan,

It's a little late here, but I've tried to put all my thoughts in order on
this topic.

On Sun, May 4, 2014 at 9:18 PM, Ryan Newton <rrnewton at gmail.com> wrote:

> Hi John & Carter,
>
> Deferring for a moment issues with CAS on lazy/pointer values, which
> pertain to Carter's question, I want to understand the ordering concern WRT
> only the "IntArray" primops that Johan listed.  First, to my knowledge GHC
> doesn't do any reordering of effectful memory operations (e.g.
> readMutVar/writeMutVar).  That is, I thought that threaded "State#" param
> was ironclad from the compiler's point of view.  (In fact, if GHC does any
> optimization of these imperative bits, could someone point me to it?)
>

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.

>
> For Johan's primops to work, each primop must represent a full memory
> fence that is respected both by the architecture, and by *both* compilers
> (GHC & LLVM).  Since I don't think GHC is a problem, let's talk about LLVM.
>  We need to verify that LLVM understands not to float regular loads and
> stores past one of its own atomic instructions.  If that is the case (even
> without anything being marked "volatile"), then I think we are in ok shape,
> right?
>

Provided the operations are SequentiallyConsistent (could probably use
Acquire/Release for reads/writes) I think LLVM will handle this
appropriately.

>
> In the grand scheme of things isn't this a place where purity has done us
> good?  All the memory traffic related to pure computation is and should be
> separate from these primops on mutable vars and arrays, and there shouldn't
> need to be any special ordering constraints *between* those two classes,
> should there?
>

Perhaps.  But it's still important to get ordering right WRT multiple
mutable ops, so I'm not sure that purity actually helps that much, except
that we can get away with underspecified operations moreso than in C++.
(also x86 has a stronger model than other archs, it's possible that we
currently get away with stuff that's unsafe on other platforms)

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.
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.

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.

Best,
John

> (Part 2)* CAS on lazy/pointer values* -- this bit *was *an ill-specified
> mess to begin with, for sure ;-).  In part, the problem was that it was
> somewhat unusual and sussed out other cabal/GHC<https://github.com/rrnewton/haskell-lockfree/issues/10> issues
> (including a regression in 7.8<https://github.com/rrnewton/haskell-lockfree/issues/28>that I think is a GHC bug,  but haven't filed yet [where a spurious "!" on
> a function arg of "Any" type changes behavior]).  Even once the commitment
> was made to use the "ticketed" approach.  (Carter, it's described in this
> trac ticket <https://ghc.haskell.org/trac/ghc/ticket/8157>.)
>
> Johan, FYI, I think we should actually backpedal on casMutVar# and
> casArray# and not expose a type like the one we have in 7.8:
>
>    MutableArray# s a -> Int# -> a -> a -> State# s -> (# State# s, Int#, a #)
>
>
> I can't think of any good reason to use it, since we should never trust
> that "a" return value -- it's poison, and covering it up successfully
> requires careful attention to NOINLINEs<https://github.com/rrnewton/haskell-lockfree/issues/5>.
>  Rather, for 7.10, better to commit directly IMHO to the "Any" type to beat
> back the compiler:
>
>   casMutVarTicketed# :: MutVar# RealWorld a -> Any a -> Any a ->
>                State# RealWorld -> (# State# RealWorld, Int#, Any a #)
>
> Cheers,
>   -Ryan
>
>
>
>
>> IMHO I think the desire to include these features is leading to a
>> slightly cavalier attitude towards reordering concerns.  Even assuming that
>> the Cmm code generator doesn't reorder reads/writes around `CallishMachOp`,
>> I don't see why this behavior should always be true, leading to possible
>> future pain.  Also, it's possible that LLVM may decide to reorder memory
>> accesses AIUI because the underlying LLVM variables won't be synchronized.
>>
>> In a nutshell, even though everything may work now I suspect it'll become
>> an ill-specified mess in a few years time.  I don't have a ton of
>> experience implementing these sorts of features in compilers though, so
>> probably only worth a half cent.
>>
>> John L.
>> On May 4, 2014 3:10 AM, "Johan Tibell" <johan.tibell at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I found myself needing atomic operations on basic, mutable numeric
>>> values. I wrote a short design doc that I'd like feedback on:
>>>
>>> https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops
>>>
>>> I will try to implement these for 7.10.
>>>
>>> -- Johan
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140504/530b4bcd/attachment.html>