[concurrency-interest] JMM and reorderings

thurstonn 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
> guarantees
> (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
intra-thread guarantees;
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 mailing list