[concurrency-interest] JMM and reorderings

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

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


More information about the Concurrency-interest mailing list