JMM and reorderings

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

JMM and reorderings

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



Reply | Threaded
Open this post in threaded view
|

Re: JMM and reorderings

Hans Boehm

On Mon, May 5, 2014 at 9:59 AM, thurstonn <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: JMM and reorderings

thurstonn
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


_______________________________________________
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?

Reply | Threaded
Open this post in threaded view
|

Re: JMM and reorderings

Hans Boehm

On Mon, May 5, 2014 at 12:02 PM, thurstonn <[hidden email]> 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

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JMM and reorderings

oleksandr otenko
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