[cpp-threads] Preparing for Oxford

[Hans Boehm]

Herb -

I agree that there are still some difficult open issues here.  But from my
perspective, I don't see a way to avoid them, no matter what we do.  I
think that at least Peter and I were converging somewhat, and we can
put a reasonable proposal together by Oxford that accomodates low-level
atomics.

I agree that by doing this, we incur some risk that we will find a bug
later, and will need to fix it.

>From my perspective, there are other problems with pursuing only the
SC atomics route:

1) As far as I know, there are still unresolved implementation issues.
If we all agree that hardware will efficiently support SC atomics (and
I personally hope we will), then these indeed become easier to specify.
But certainly some people are advocating alternatives that make me very
uncertain that stronger atomics would be easier to specify.

2) If the memory model supports only SC atomics, or some other flavor
of strong atomics, it is likely to be much harder to add weak atomics
later.  I think it's much easier to do things the other way around,
and provide simpler characterizations for programs that use only SC
atomics as theorems.

3) I think it probably makes sense to add abstractions for some non-SC
idioms like reference counting.  But I'm not sure that this can really be
pulled off adequately without defining a memory model that can deal with
weakly ordered atomics underneath.  We probably do need unordered
counters.  I'm not sure you can precisely define what those mean without
addressing the same issues we have been trying to address for the low
level primitives.  In some other cases, like garbage-collector mark bits
(or the sieve of Eratosthenes example in my PLDI paper), you really
want something like an atomic bit vector, in which case the "set"
operation is essentially an unordered (or possibly release, but without
the trailing fence for SC) store.  And describing what that means is
essentially the same problem as defining store_release.  (I think that
some of these things are a bit easier to throw in in Java, since it
addresses some of the resulting issues in its treatment of "causality",
which, I think, most people agree is more complex than what we have been
discussing.)

4) My sense of the committee was that people did generally want access
to the low-level non-SC operations.

I'm certainly not opposed to also exploring an SC-atomics-only version of
the proposal.  If we assume the appropriate hardware facilities, it can
be simpler.  And having both would be useful for comparison purposes.
But I'm not convinced it solves our problems.

We just haven't had the time to pursue the higher level abstractions
for things like reference counting.  If someone wants to pursue that ...

Hans

On Tue, 26 Dec 2006, Herb Sutter wrote:

> Thinking over the past month's discussion, what effect will/should this have on the C++ MM and atomics proposals for the April meet in Oxford? Here's my suggestion:
>
>   1. Eliminate, or at least split out, the low-level non-SC atomics features.
>   2. Add type abstractions for a few key uses of non-SC atomics (e.g., DCL, RC).
>   3. (Hard to do for Oxford) Simplify the proposal to use a single ordering relation.
>
> Details follow.
>
>
> Re #1: I'm concerned that the "raw, low-level" form of non-SC atomics isn't ready for vote in Oxford and will delay making progress on the rest of the MM/atomics proposals. Two reasons: (a) it's not as fully baked (we're still having fairly fundamental discussions about how to specify them); and (b) it's more controversial.
>
> Suggestion: Before Oxford, we should update the proposals to either eliminate, or at least split out, the low-level non-SC atomics. My preference is to eliminate them; but if someone really wants to push for adopting these, we need to be able to vote on them separately from the rest of the proposals, and to enable that they should be in one lump somewhere in a single section or a separate paper so that we can do the usual vote-splitting ("vote on everything but section X.Y, then vote on X.Y"). Otherwise, if we're forced to vote on it as a package deal, and low-level non-SC atomics should fail, it will delay everything.
>
> BTW, Hans suggested the following problem with dropping unordered atomics:
>
> > - Dropping unordered atomics.  I'm unconvinced that's viable on
> > architectures like PowerPC and ARM, where acquire loads and release
> > stores require a fence.  It would result in a lot of platform-specific
> > low-level code for those platforms.
>
> FWIW, ARM at least may not be that bad. I've been talking with the ARM folks and they are telling me that they're leaning heavily toward cheap acq/rel, both because they were already considering that path and also because of Prism.
>
> General principle: Please let's not forget that while we on the software side have always been willing to do a lot of heavy lifting to run on whatever the hardware gave us, and the bulk of the work and "give" here remains on our ever-willing SW side, the hardware side can now be expected to give a little too. Bringing the two together in a programmable way is a key point of this whole exercise.
>
> My own opinion is that, regardless of what we bless or don't bless, the market will probably tend to select for hardware with efficient SC atomics anyway (because non-SC atomics aren't reliably programmable by humans).
>
>
> Re #2, quoting Hans:
>
> > We want unordered atomic operations, since they are cheaper in some
> > contexts, and are occasionally sufficient.  They are unfortunately,
> > tricky to use correctly and, as we keep discovering, even trickier to
> > define correctly.
>
> The way to deal with that is to provide abstractions that hide the brittle or nonportable low-level facilities. As discussed previously, we should add specific types as abstractions for the non-SC atomics use cases that we think are important to support for performance reasons, such as DCL and reference counting (e.g., dcl_pointer or rc_uint or something whose built-in operations have the desired ordering semantics). I think this is essential even if #1 weren't a problem, because it's the only realistic path now on the table to something that is weaker than SC atomics and still usable (even for experts).
>
> We talked about doing this in Redmond and Portland, and as I recall there was had widespread agreement for this approach, but I haven't seen any more recent versions of the proposals -- have these been added?
>
>
> Re #3: I know a lot of work has been put into the current C++ MM proposal, but my concern is only increasing that its current formulation is just too complex (and not just because this month's threads have discussed increasing the number of relations to 5 or 6, some primary and some secondary). In Redmond and Portland, even the authors of the C++ MM proposal didn't always have the same understanding of what the proposal said about a given code sample. Some of this is unavoidable in any complex proposal, but I worry that the current complexity can be a killer for not just usability but implementability. (If I had a dollar for every time I've heard Hans say he's not sure if JMM implementations get a given feature right, I could buy a grande latte or three.)
>
> I would like to strongly encourage us to attempt defining the MM using a single relation. If I can't convince enough people of that, then I'd try to encourage at least something less than 4-6+ different interacting relations. As you know, I think a single relation is possible, and so far all the concerns I know of that Hans raised to me about whether Prism's single-relation approach works have been addressed (including in some side discussions in Portland).
>
> I don't care if the single relation is Prism's or not. I do care that the MM be understandable, because that affects both usability and implementability, and outside this small group there's a widespread feeling that the Java MM, and anything of equivalent complexity, just isn't understandable (sorry) despite it many other strengths (and there are many).
>
> Just some thoughts.
>
> Herb
>
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>