Adding atomic primops

[Carter Schonwald]

what sailed in ghc 7.2?


On Mon, May 5, 2014 at 12:46 AM, Ryan Newton <rrnewton at gmail.com> wrote:

> One last comment -- none of the above is to suggest that I don't think we
> should eventually have a memory model (a la Java or C++11).  But I (and
> Johan) don't think the addition of the primops Johan listed should wait on
> it.  Further, I don't think these primops make the state of affairs any
> worse, given that we've *already* had the combination of IORef operations
> & parallel IO Threads for a long time, without a memory model.
>
> I think the informal agreement we've been muddling along with is something
> like this:
>
>    - IORef operations have the same behavior as the analogous C
>    operations -- no implied synchronization
>    - all IORef ops are "volatile" wrt GHC (GHC won't reordered)
>    - atomicModifyIORef does what its name implies
>
> Though I confess, I'm personally unclear on what the agreement is in at
> least two places:
>
>    - What Haskell operations constitute grabbing a "lock" to protect
>    IORef reads and writes?  (We often use MVar based strategies for locking,
>    but do they give a *guarantee* that they provide the necessary memory
>    fences for the previous/subsequent IORef operations?)
>    - Is the de-facto "volatile" status I implied before extended to the
>    backends (C / LLVM)?  I don't know but assume not.  Note that even if not,
>    this doesn't cause a problem for the proposed atomic primops, all of which
>    are themselves
>
> Perhaps I and others get away with this level of murkiness because we
> depend on IORefs so little, with so much happening in the pure code ;-).
>
> Ah, and last of all -- while we do need to sort out all this stuff -- I
> want to point out that adding Johan's proposed primops isn't the key
> decision point.  That ship sailed with 7.2 ;-).  This is just about
> fleshing out what's already there (e.g. fetch and Xor in addition to fetch
> and Add) and improving the implementations by going to in-line primops.
>
> Best,
>   -Ryan
>
>
> On Mon, May 5, 2014 at 12:25 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>
>> 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?
>>>
>>
>> Clarification -- this is assuming we're using the
>> "SequentiallyConsistent" setting in the LLVM backend to get full fences on
>> each op, which correspond to the gcc-compatible __sync_* builtins:
>>
>>    http://llvm.org/docs/Atomics.html#sequentiallyconsistent
>>
>>
>>
>
> _______________________________________________
> 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/20140505/b00956ee/attachment-0001.html>