Adding atomic primops

[Edward Kmett]

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"<http://www.cs.nmsu.edu/~scooper/CS574/papers/threads-library.pdf>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 at 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 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/20140513/44e175b8/attachment.html>