[concurrency-interest] JMM and reorderings
thurston at nomagicsoftware.com
Mon May 5 15:02:27 EDT 2014
Hans Boehm wrote
> Did you have something else in mind?
Grrr, yes - the code should have been:
Initially, x == y == 0
Thread 1 Thread 2
r1 = x x = 5
y = 5 r3 = y
r2 = x
But that's not the interesting part (r1 == r2 == r3 == 0)
> But what about the following?
> r2 == 0, r1 == 5
> Which is equivalent to allowing:
> r2 = x
> r1 = x
> y = 5
> I want to say that that is a violation of intra-thread conistency
> (or intra-thread semantics if you prefer), but it's not clear to me where
> specifically the JMM would prohibit that.
Assuming nothing is declared as volatile, that is clearly allowed. This
kind of thing is likely to happen if Thread 1 really looks like
r17 = a.x;
r1 = b.x;
y = 5;
r2 = a.x;
and a and b are really references to the same object. The compiler is
likely to reuse the load to r17 to compute r2, effectively reversing the
loads into r1 and r2.
There are also several kinds of hardware that allow reordering of loads
from the same location.
Racing accesses to ordinary data have surprising and sometimes poorly
defined semantics in Java ...
Concurrency-interest mailing list
Concurrency-interest at .oswego
That's surprising, i.e. that r2 = 0, r1 = 5 is allowed
I guess my thinking is that this violates the *intra-thread* semantics of
the Thread 1 code, viz.
program order is dictating that r1 can never "see a later value of x" than
r2 - ok that's not very formal I guess, but it seems to violate the
yes, there is no happens-before and there is no explicit dependency between
r1 and r2 . . . so all bets are off?
View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/JMM-and-reorderings-tp10973p10975.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
More information about the Concurrency-interest