Oh, just the first CAS primop -- the initial decision to include these kinds of ops.
Sent from my phone. On May 5, 2014 12:59 AM, "Carter Schonwald" <[email protected]> wrote: > what sailed in ghc 7.2? > > > On Mon, May 5, 2014 at 12:46 AM, Ryan Newton <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
