[concurrency-interest] JMM and reorderings
boehm at acm.org
Mon May 5 16:12:21 EDT 2014
On Mon, May 5, 2014 at 12:02 PM, thurstonn <thurston at nomagicsoftware.com>wrote:
> 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 ...
> 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?
> Yes. All bets are off. And the alternative would disable some common
compiler optimizations and would require enforcement overhead on certain
kinds of hardware.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest