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. |
On Mon, May 5, 2014 at 9:59 AM, thurstonn <[hidden email]> wrote: Given the following: 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?
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 |
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 _______________________________________________ Concurrency-interest mailing list [hidden email] http://cs.oswego.edu/mailman/listinfo/concurrency-interest 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? |
On Mon, May 5, 2014 at 12:02 PM, thurstonn <[hidden email]> wrote: Hans Boehm wrote 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
_______________________________________________ Concurrency-interest mailing list [hidden email] http://cs.oswego.edu/mailman/listinfo/concurrency-interest |
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 |
Free forum by Nabble | Edit this page |