Design discussion for atomic primops to land in 7.8

[Ryan Newton]

There's a ticket that describes the design here:
    http://ghc.haskell.org/trac/ghc/ticket/8157#comment:1
It is a fairly simple extension of the casMutVar# that has been in since
7.2.  The implementation is on the `atomics` branch currently.

Feel free to add your views either here or on that task's comments.

One example of an alternative design would be Carter's proposal to expose
something closer to the full LLVM concurrency
ops<http://llvm.org/docs/Atomics.html>
:

Schonwald <carter.schonwald at gmail.com> wrote:

> i'm kinda thinking that we should do the analogue of exposing all the
> different memory model level choices (because its not that hard to add
> that), and when the person building it has an old version of GCC, it falls
> back to the legacy atomic operations?
>
> This also gives a nice path to how to upgrade to the inline asm approach.
>

These LLVM ops include many parameterized configurations of loads, stores,
cmpxchg, atomicrmw and barriers.  In fact, it implements much more than is
natively supported in most hardware, but it provides a uniform abstraction.

My original thought was that any kind of abstraction like that would be
built and maintained as a Haskell library, and only the most rudimentary
operations (required to get access to process features) would be exposed as
primops.  Let's call this the "small" set of concurrent ops.

If we want the "big set" I think we're doomed to *reproduce* the logic that
maps LLVM concurrency abstractions onto machine ops irrespective of whether
those abstractions are implemented as Haskell functions or as primops:

   - If the former, then the Haskell library must map the full set of ops
   to the reduced small set (just like LLVM does internally)
   - If we instead have a large set of LLVM-isomorphic primops.... then to
   support the same primops *in the native code backend *will, again,
   require reimplementing all configurations of all operations.

Unless... we want to make concurrency ops something that require the LLVM
backend?

Right now there is not a *performance* disadvantage to supporting a smaller
rather than a larger set of concurrency ops (LLVM has to emulate these
things anyway, or "round up" to more expensive ops).  The scenario where it
would be good to target ALL of LLVMs interface would be if processors and
LLVM improved in the future, and we automatically got the benefit of better
HW support for some op on on some arch.

I'm a bit skeptical of that proposition itself, however.  I personally
don't really like a world where we program with "virtual operations" that
don't really exist (and thus can't be *tested* against properly).  Absent
formal verification, it seems hard to get this code right anyway.  Errors
will be undetectable on existing architectures.

  -Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130822/4db6cf1f/attachment.htm>