The C11 and C++11 Concurrency Model

135
int main() {
atomic_int x = 0;
atomic_int y = 0;
int a1,a2;
{{{ { a1 = x.load(relaxed);
y.store(a1,relaxed); }
||| { a2 = y.load(relaxed);
x.store(a2,relaxed); }
}}}
return 0;
}
c:R RLX x=42 g:R RLX y=42
sb sb
rf rf
f:W RLX y=42 j:W RLX x=42
Forbidden by x86, Power and ARM architectures. C/C++11 should forbid this.
As the formal model stands, any single value may be read by the two atomic reads.
The designers of the memory model intend this execution of the program to be forbidden,
and the standard imposes a restriction in 29.3p9 that is intended to forbid this sort of
execution. In fact, in 29.3p10 the standard says explicitly that 29.3p9 forbids it:
29.3p10
[...]
// Thread 1:
r1 = y.load(memory order relaxed);
x.store(r1, memory order relaxed);
// Thread 2:
r2 = x.load(memory order relaxed);
y.store(r2, memory order relaxed);
[29.3p9 implies that this] may not produce r1 = r2 = 42 [...]
Thisexecution oftheprogram violates programmer intuition: thefact that thewritten
value is dependent on the read value implies a causal relationship, as do the reads-from
edges. Together these edges form a cycle, and that cycle is what seems to violate intuition
and separate this from more benign executions. Analogous programs on x86, Power and
ARM processors would all forbid this execution, and the standard explicitly forbids this
execution. Moreover, allowing executions of this sort for some types, pointers for example,
would allow us to write programs that violate run-time invariants by, say, forging pointers
— see Section 5.10.3 for a discussion of Java’s safety guarantees in the context of the thin-