Presentation: Understanding OrderAccess

Doerr, Martin martin.doerr at
Wed Nov 30 08:36:21 UTC 2016

Hi Andrew,

I know that. My point was the global effect of Thread 1's barrier.

Best regards,

-----Original Message-----
From: Andrew Haley [mailto:aph at] 
Sent: Dienstag, 29. November 2016 20:02
To: Doerr, Martin <martin.doerr at>; David Holmes <david.holmes at>; hotspot-dev developers <hotspot-dev at>
Subject: Re: Presentation: Understanding OrderAccess

On 29/11/16 17:50, Doerr, Martin wrote:

> I mean a scenario like in 5.1 " Cumulative Barriers for WRC" in [1].
> Thread 1 reads a value from Thread 0, Thread 1 publishes something 
> e.g. by a releasing store (which could be lwsync + store on PPC64) and 
> Thread 2 acquires this value (or relies on address dependency based 
> ordering).
> The barrier must order Thread 0's store wrt. Thread 1's store in this case.
> E.g. Thread 1 could have updated a data structure referencing stuff 
> from Thread 0. I think we all rely on that Thread 3 sees at least the 
> same changes from Thread 0 when accessing this data structure. So this 
> "cumulative" property is relevant for hotspot's OrderAccess functions.

You can't rely on address dependency ordering in a language like C++ unless you use something like memory_order_consume: the compiler is capable of optimizing your code so that it doesn't use the address you think it should be using.  That example is only valid for assembly code.  Acquire is fine.


More information about the hotspot-dev mailing list