[cpp-threads] memory model

[Peter Dimov]

Doug Lea wrote:
>
> I'll prod Bill to answer. But in the mean time you might
> try the same reasoning with the collection of examples at
> http://www.cs.umd.edu/~pugh/java/memoryModel/CausalityTestCases.html
> It's conceivable that none of them apply in C++, but  I sorta doubt
> it.

I'll take a look, but can you give me some hints about what I need to look 
for?

To step back a bit, what we're talking about is limited versions of the 
acquire unidirectional constraint, such that:

Code conditional acquire prevents subsequent operations that can be executed 
conditionally depending on the value v being loaded to become visible before 
the current load. It does not inhibit reordering of independent operations.

Definition of "can be executed conditionally": there exist two values v1 and 
v2 such that for v == v1 the operation op is executed and for v == v2 the 
operation op is not executed.

Data dependency is similar: for every two different values v1 and v2, when v 
== v1, the operation op accesses memory location a1, and when v == v2, op 
accesses a2, where a1 != a2.

This definition makes x = a[ r1? 0: 1 ] code conditional instead of data 
dependent.

What this means in practice when these labels are used:

- a compiler can only reorder if it can prove that the operation is not code 
conditional (or data dependent.)

- when the hardware is known to track code and data dependencies and inhibit 
reordering based on them, the compiler can take advantage of these implicit 
barriers and avoid explicit synchronization.