[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