[concurrency-interest] JMM and reorderings

Hans Boehm boehm at acm.org
Mon May 5 14:12:38 EDT 2014


On Mon, May 5, 2014 at 9:59 AM, thurstonn <thurston at nomagicsoftware.com>wrote:

> Given the following:
>
> Initially, x == y == 0
> Thread 1       Thread 2
> r1 = x            r3 = y
> y = 5             x = 5
> r2 = x
>
> Thinking about legal outcomes under the JMM:
> r1 == r2 == r3 == 0 is a well-known legal outcome given allowed
> reorderings/optimizations
>
> Indeed, that is not a very interesting outcome, since it is the result of
a sequentially consistent/interleaving-based execution:

r3 = y; r1 = x; y = 5; r2 = x; x = 5;

Did you have something else in mind?


>
> 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 ...

Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140505/7b7996dd/attachment.html>


More information about the Concurrency-interest mailing list