Presentation: Understanding OrderAccess

Doerr, Martin martin.doerr at sap.com
Tue Nov 29 17:50:32 UTC 2016


Hi Andrew,

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.

Best regards,
Martin


[1] http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf

-----Original Message-----
From: Andrew Haley [mailto:aph at redhat.com] 
Sent: Dienstag, 29. November 2016 15:07
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 13:08, Doerr, Martin wrote:
> Also storeStore barriers are expected to be transitive or "cumulative" as the property is called in PPC64 documentation.
> If one thread releases something which is based on something else 
> which was written by another thread, a third thread which acquires it, is expected to see that in a consistent way. Do you agree?

It depends.  What exactly do you mean by "is based on"?

Andrew.



More information about the hotspot-dev mailing list