[cpp-threads] Preparing for Oxford

[Paul E. McKenney]

On Tue, Dec 26, 2006 at 04:29:43PM -0800, 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.

More controversial in what group?  In PRISM v0.9.1, the only justification
I find for SC is a citation of a 27-year-old paper by Lamport.  Now there
can be no doubt of Lamport's insight and the value of his work, but
wasn't this particular paper focused on proofs of correctness rather
than on programming?  And given the very small number of shared-memory
parallel machines and the very small number of people with experience
programming them in the late 1970s, wouldn't it be time to revisit this
assumption by now in any case?  There has been considerable evolution
of practice over the past quarter century.

There are a number of common programming idioms that are not SC, but
which are well-understood and can be both taught and used reliably.

> 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).

The market indeed has done so, but for software abstractions built on
top of commodity hardware.  One extremely popular such abstraction,
despite both real and imagined faults, is locking.  This abstraction
provides SC view of the data being protected.  Another such abstraction
is database-style transactions (the jury is still out on the more recent
transaction-memory implementations, though it seems likely that at least
some form of TM will be valuable).

These abstractions can (and have) been implemented efficiently on non-SC
machines.  Thus, pushing SC into the compiler is pushing SC too far down
the stack.

> 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).

How are we measuring usability?  Keep in mind that the raw compiler must
serve a very large variety of users.  And isn't it possible that the
pain you may have witnessed is at least in part due to people working
at too low a level?  Low-level atomic operations have been quite valuable
to me, but only when used properly -- in other words, sparingly.

> 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).

By "single relation", you mean "relation that defines a sequentially
consistent ordering"?

							Thanx, Paul

> 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