[cpp-threads] Slightly revised memory model proposal (D2300)

[Herb Sutter]

I haven't been able to follow the deluge of recent discussion, but I just reread Sarita's note from last week:

> I am assuming there is still a need to convey a simple model to the
> "masses" who will use locks and SC atomics (and not relaxed atomics).
> And that there isn't yet a simple enough alternative to "SC for DRF
> programs" for this purpose.

That was also my understanding, and that beyond that (and primarily for PPC) we were also going to support a relaxed model as a pure extension. In particular, a programmer who doesn't touch the relaxed stuff shouldn't be affected by the presence of the extensions.

Ideally, an implementer who doesn't touch the relaxed stuff shouldn't be affected either (e.g., I hope the added complexity in the specification would be mostly limited to the extensions). I realize this may not be ideally achievable but I had the impression that Hans and Clark were still trying to make an effort in this direction.

Sarita continued:
> If the above is true, then doesn't it follow that we have to define
> data-race-free in an SC-centric way? It then seems to follow that the
> example below should not be classified as drf. One possible simple (not
> necessarily best and not yet proven correct) way to do that is to say
> that programs with relaxed atomics (in SC executions) are not considered
> drf. Then immediately such programs require reasoning with the more
> complex model, but that's the cost of using relaxed-atomics. There may
> be other options as well that articulate limited uses of relaxed-atomics
> that also allow using SC-centric drf definition.
>
> In summary, the point I am making is that if a data race is not defined
> in terms of SC executions, then we lose a lot of what we were after (at
> least in several previous discussions). In yet other words, if people
> restricting themselves to sc atomics have to reason with the complex
> model anyway, then it isn't clear that the distinction between relaxed
> and sc atomics is driven by "ease-of-use."

My understanding was that we had decided to pursue a path like that outlined above. I haven't seen any replies to Sarita's note -- am I safe in believing that we're still on the general path she describes?

Herb