Presentation: Understanding OrderAccess
martin.doerr at sap.com
Tue Nov 29 17:50:32 UTC 2016
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.
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"?
More information about the hotspot-dev