[cpp-threads] Preparing for Oxford

[Herb Sutter]

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