[concurrency-interest] Ordering Question
Gil Tene
gil at azul.com
Tue Jul 19 22:40:51 EDT 2016
Not an authoritative answer Mike, but:
1. Since (to my understanding) the effective StoreStore-fence-like behavior of lazySet/putOrdered occurs *before* the store to X below, and not after it, it has no effect (different from a regular store) on ordering in the sequence.
2. The a volatile read does not prevent previous stores from being reordered past it.
As a result of these two observations, T1 can validly be reordered to:
T1:
1) B = Y (volatile read)
2) X = 1 (lazySet/putOrdered)
Which would then make the result you ask about quite possible:
T1 T2
Y = 1
B = Y
A = X
X = 1
[Note that even if the StoreStore-like-fence behavior was after the store (which I believe isn't the case), the reordering above would be valid, since it would still not prevent crossing the volatile read]
— Gil.
> On Jul 19, 2016, at 7:11 PM, Michael Barker <mikeb01 at gmail.com> wrote:
>
> Hi,
>
> I have a question around ordering of events.
>
> Given, threads (T1, T2), and variables (A, B, X, Y) where X and Y are shared on the heap and visible to T1 and T2.
>
> Initially:
>
> X = 0
> Y = 0;
>
> T1:
> 1) X = 1 (lazySet/putOrdered)
> 2) B = Y (volatile read)
>
> T2
> 3) Y = 1 (compare and set)
> 4) A = X (volatile read)
>
> Is it possible to get a final state of A = 1 and B = 0?
>
> My current suspicion is that it is, due to 1) and 2) being reordered. If so, can the final state of A=1, B=0 be prevented by strengthening 1) to be a volatile store?
>
> Regards,
> Michael Barker.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160720/856863e1/attachment.sig>
More information about the Concurrency-interest
mailing list