[concurrency-interest] Can a volatile read be reordered before a lazySet?

Gil Tene gil at azulsystems.com
Wed Dec 31 13:41:13 EST 2014


It would vary by processor. But in most processors, store buffer contents are usually drained as soon as their associated in-flight L1 cache line arrives so that the store can be merged into it. On processors that implicitly maintain store order, the drain order if usually a FIFO. I.e. stores that have lines ready won't drain before that were ahead of them but don't yet have lines available.

So in general stuff will be in the buffer for a time length that is on the order of an LLC miss (L3 on modern Xeons).


On Dec 31, 2014, at 8:50 AM, Oleksandr Otenko <oleksandr.otenko at oracle.com<mailto:oleksandr.otenko at oracle.com>> wrote:

yes, I got you, and my clumsy question really should have read "upon what condition will they drain on their own"

Like, N tics? Coherence traffic ceased? Hyperthreaded sibling does something?

Alex

On 31/12/2014 16:36, Vitaly Davidovich wrote:

Your previous reply talked about performing a lazy write and then possibly having it stall indefinitely (or until preemption, as you say) because nobody forces the buffer to drain.  I'm saying if the write actually occurs, it'll drain on its own.

Sent from my phone

On Dec 31, 2014 11:31 AM, "Oleksandr Otenko" <oleksandr.otenko at oracle.com<mailto:oleksandr.otenko at oracle.com>> wrote:
Yes, but do they drain if no one writes anything?

Alex

On 31/12/2014 15:18, Vitaly Davidovich wrote:

Write buffers don't *need* to be drained, they drain automatically anyway.  At least that's the case for intel.  So the issue here is more like what Gil said - compiler can reorder the code causing a deadlock.

Sent from my phone

On Dec 31, 2014 9:45 AM, "Oleksandr Otenko" <oleksandr.otenko at oracle.com<mailto:oleksandr.otenko at oracle.com>> wrote:
Not sure why you say (3). Since lazySet is not part of JMM, I am only assuming it is pretty much like an ordered store on x86.

In the presence of write buffers the loop may spin indefinitely, yet the lazy-stored write won't become visible to the pong thread - there'd be nothing to cause the buffers of the ping thread to flush. So ping effectively will appear to perform all the loads of the indefinite loop ahead of the store.

In reality the only event that would cause the write buffers to flush, is the thread preemption.


Alex


On 31/12/2014 07:20, Nitsan Wakart wrote:
Re-read the Shipilev "JMM Pragmatics" reference again last night, and discussed with Gil. I think that cup of coffee was nowhere near enough :-). In particular:
"If IUC this means stores and volatile loads are conservatively not reordered" is FALSE because the premise "IUC" is false. I did not understand correctly which leads me to amend my comment:
1. There's technically nothing to stop reordering between the store and load.
>  theLong.lazySet(1L);
>  Object o = theRef.get();
2. There's technically nothing to stop reordering between the store and load.
>  long l = theLong.get() + 1; // LOADLOAD
>  theLong.lazySet(l); //STORESTORE
>  Object o = theRef.get(); // LOADLOAD
3. I still think the while loop presents a different case to normal flow. So for now I still hold that the lazySet cannot be moved after the while loop.

My sincere apologies for the confusion.
Happy holidays to all.



_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>
http://cs.oswego.edu/mailman/listinfo/concurrency-interest






_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu<mailto: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/20141231/a6873862/attachment.html>


More information about the Concurrency-interest mailing list