I'd be pretty comfortable relying on the existing implementation for now as long as we know it is the sort of thing we should shore up before too long.

Ultimately "Threads Cannot Be Implemented As a Library" but you can fake it for a long time. The user base of such features is pretty savvy and if we're force to go a bit overboard adding fences prophylactically it doesn't cost nearly as much today as it did even 2 years ago.

-Edward

On Mon, May 12, 2014 at 11:18 PM, Johan Tibell <johan.tibell@gmail.com> wrote:

Hi all,

I'm not sure how to continue from here. The current backend story feels a bit shaky. Do we think we accurately need to reflect the memory model in Cmm before we should venture into this area at all, or are we comfortable relying on the current implementation of CallishMachOps with the knowledge that if we ever want to move loads/stores past those calls, we need to address the memory model issue then?

I'm less concerned about actually picking a memory model. I think we should borrow what C/C++ did and just pick a couple (maybe even just 2) of the consistency levels on their "ladder" and support those. We can always add more relaxed ordering guarantees later.

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