Threads and Locks - The Java Language Specification - page 582

Table 17.6. Happens-before consistency is not sufficient
The code shown in Table 17.6 is correctly synchronized. This may seem surprising,
since it does not perform any synchronization actions. Remember, however, that a
program is correctly synchronized if, when it is executed in a sequentially consistent
manner, there are no data races. If this code is executed in a sequentially consistent
way, each action will occur in program order, and neither of the writes will occur.
Since no writes occur, there can be no data races: the program is correctly synchron-
ized.
Since this program is correctly synchronized, the only behaviors we can allow are se-
quentially consistent behaviors. However, there is an execution of this program that is
happens-before consistent, but not sequentially consistent:
r1 = x; // sees write of x = 1
y = 1;
r2 = y; // sees write of y = 1
x = 1;
This result is happens-before consistent: there is no happens-before relationship that
prevents it from occurring. However, it is clearly not acceptable: there is no sequen-
tially consistent execution that would result in this behavior. The fact that we allow a
read to see a write that comes later in the execution order can sometimes thus result in
unacceptable behaviors.
Although allowing reads to see writes that come later in the execution order is some-
times undesirable, it is also sometimes necessary. As we saw above, the trace in Table
17.5 requires some reads to see writes that occur later in the execution order. Since
the reads come first in each thread, the very first action in the execution order must
be a read. If that read cannot see a write that occurs later, then it cannot see any value
other than the initial value for the variable it reads. This is clearly not reflective of all
behaviors.
We refer to the issue of when reads can see future writes as causality , because of is-
sues that arise in cases like the one found in Table 17.6 . In that case, the reads cause
the writes to occur, and the writes cause the reads to occur. There is no “first cause”