[concurrency-interest] JMM and reorderings
oleksandr.otenko at oracle.com
Wed May 7 18:00:33 EDT 2014
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.
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
> (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
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest