[concurrency-interest] JMM and reorderings

Oleksandr Otenko 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.


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
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140507/bdbd5697/attachment-0001.html>


More information about the Concurrency-interest mailing list