ryan, any thoughts on the (valid!) concern John Lato raises?

I know you mentioned fighting ghc optimizations when writing concurrent code a while ago, and i believe I asked if you could document the issues some time so we can all think about how to make the sitch easier, could you share your thoughts?

AFAIK, there isn't a clear "this is the memory ordering rules" even in an informal sense for ghc core / stg / cmm, and maybe we need to pin down some "informal" guarantees we want to hold?

-Carter

On Sun, May 4, 2014 at 6:32 PM, John Lato <jwlato@gmail.com> wrote:

Hello,

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@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@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs