Presentation: Understanding OrderAccess

[Doerr, Martin]

Hi Andrew,

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

Best regards,
Martin

-----Original Message-----
From: Andrew Haley [mailto:aph at redhat.com] 
Sent: Dienstag, 29. November 2016 20:02
To: Doerr, Martin <martin.doerr at sap.com>; David Holmes <david.holmes at oracle.com>; hotspot-dev developers <hotspot-dev at openjdk.java.net>
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.

Andrew.