Presentation: Understanding OrderAccess
aph at redhat.com
Tue Nov 29 19:01:56 UTC 2016
On 29/11/16 17:50, Doerr, Martin wrote:
> I mean a scenario like in 5.1 " Cumulative Barriers for WRC" in .
> 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