Sequentially consistent also corresponds to, according to the LLVM docs: "the C++0x/C1x memory_order_seq_cst, Java volatile, and the gcc-compatible __sync_* builtins", so we'll be in good company.
On Tue, May 20, 2014 at 5:01 PM, Johan Tibell <johan.tib...@gmail.com>wrote: > After some discussion with Simon, I will go ahead and try to implement > fully sequentially consistent versions of these primops. We can add other > versions that take the consistency model as an argument later, if needed. > > > On Thu, May 15, 2014 at 9:03 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > >> Hey Johan, >> on https://ghc.haskell.org/trac/ghc/ticket/7883 Ryan helped articulate >> what he'd want wrt memory ordering semantics. >> >> One point is that It might be totally valid and reasonable to provide >> *both* variants, though if we only were to do one, the strong ordering >> guarantees might be a better default, albeit your use case and others does >> benefit from using the weakest / simplest primops possible, >> >> >> On Thu, May 15, 2014 at 6:01 AM, Johan Tibell <johan.tib...@gmail.com>wrote: >> >>> I will update the wiki page (and later CmmSink) with the guarantees we >>> expect CallishMachOps to provide. We do need to pick what kind of guarantee >>> we want to provide. Options are here: >>> http://en.cppreference.com/w/cpp/atomic/memory_order >>> >>> Do we want to have these CallishMachOps to imply a full memory fence CPU >>> instruction or some more relaxed ordering (e.g. only atomicity)? >>> >>> _______________________________________________ >>> 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