# JMM and reorderings Classic List Threaded 5 messages Open this post in threaded view
|

## JMM and reorderings

 This post was updated on . :Edited: Given the following: Initially, x == y == 0 Thread 1       Thread 2 r1 = x            x = 5 y = 5             r3 = y r2 = x Thinking about legal outcomes under the JMM: r1 == r2 == r3 == 0 is a well-known legal outcome given allowed reorderings/optimizations 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.
Open this post in threaded view
|

## Re: JMM and reorderings

 On Mon, May 5, 2014 at 9:59 AM, thurstonn 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 _______________________________________________ Concurrency-interest mailing list [hidden email] http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Open this post in threaded view
|

## Re: JMM and reorderings

 In reply to this post by thurstonn Think of it this way: intra-thread semantics isn't broken; that reordering is clearly allowed, because intra-thread there are no intervening writes to x. Alex On 05/05/2014 20:02, thurstonn wrote: ```... 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. ... 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. _______________________________________________ Concurrency-interest mailing list [hidden email] http://cs.oswego.edu/mailman/listinfo/concurrency-interest ``` _______________________________________________ Concurrency-interest mailing list [hidden email] http://cs.oswego.edu/mailman/listinfo/concurrency-interest