[cpp-threads] RE: volatile, memory models, threads

[Herb Sutter]

Hans wrote:
> In my view, the main advantage of the C++ (non-)proposal would be that
> it is cheaper to implement on most architectures, incl. X86, and
covers
> all non-esoteric cases (e.g. DCL, flags to terminate wait loops).  On
> Pentium 4s, I think the performance difference is large for writes,
and
> zero for reads (admittedly the more important case).
> 
> The disadvantage over the Java approach is that you don't get
sequential
> consistency by declaring everything volatile, and there are a few
cases
> in which the stronger semantics matter, e.g. Dekker's algorithm.

Thanks. However, C++ is a systems programming language, and it has to be
possible to do the latter too.

One data point that comes to mind is that volatile data should be rare
-- this is stuff for rocket scientists only -- and that argues for not
worrying as much about getting exactly optimal performance. But on the
other hand, when those rocket scientists do this stuff, it's because
they want performance.

So here's what I would suggest considering:

  - If the performance difference is large enough on some/all
architectures so as to provide a reason not to use the feature, perhaps
that is sufficient reason to consider surfacing two abstractions, one
with most of the power and all the speed, and the other with all the
power and perhaps less speed on some systems.

  - Otherwise, surface one abstraction -- the one with all the power
(SC).

Can you explain what you mean by this being a "non"-proposal -- is it
that just this option isn't being proposed, or that there is no proposal
along the lines of Java "volatile" of any kind? I had understood
providing such an abstraction to be a key part of the memory model.

Herb