[concurrency-interest] AtomicReference.updateAndGet() mandatory updating
gil at azul.com
Fri May 26 12:09:23 EDT 2017
> On May 26, 2017, at 8:36 AM, Andrew Haley <aph at redhat.com> wrote:
> On 26/05/17 16:19, Gil Tene wrote:
>> I bellieve that making the hardware perform a store release [or
>> equivalent] to a different location is not sufficient to emulate a
>> volatile write's memory semantics, since it e.g. does not prevent
>> subsequent volatile loads of other fields from floating backwards
>> past the store release point, and then e.g. past prior non-volatile
>> stores to the compareAndSet'ed field.
> I'm not quite sure I understand this. ARMv8's store release and load
> acquire are sequentially consistent. So, as far as I can see there is
> no way that a subsequent volatile load could possibly float backwards
> past such a store.
For ARMv8, there may still be "hope":
Per the ARM ARM Instruction Set Overview (e.g. https://www.element14.com/community/servlet/JiveServlet/previewBody/41836-102-1-229511/ARM.Reference_Manual.pdf) store release and load
acquire provide Release Consistency (RCsc), [not sequential consistency]. (See 3.5.3, page 12).
Section 5.2.8 (page 29) says:
"A store-release will be observed by each observer after that observer observes any loads or stores that appear in program order before the store-release, but says nothing about loads and stores appearing after the store-release."
However, it also says:
"In addition, a store-release followed by a load-acquire will be observed by each observer in program order."
And combining this with the earlier:
"A load-acquire is a load where it is guaranteed that all loads and stores appearing in program order after the load- acquire will be observed by each observer after that observer observes the load-acquire, but says nothing about loads and stores appearing before the load-acquire."
would mean [transitively, by my interpretation] that "all loads and stores appearing in program order after a load-aquire that follows a store-release will be observed by each observer after the observer observes any loads or stores that appear in program order before the store-release"
So ***for ARMv8*** a store-release followed by a load-aquire (e.g. both the a thread local) will impose a StoreLoad order.
[This is not a general property of store-release and load-aquire]
>> Basically, there is no StoreLoad ordering [that is required to be]
>> enforced on the hardware by a store release, which makes it
> Oh yuck, this is *so* *horrible*, but I guess I'll stop worrying about
> it. The Java spec is what it is, for whatever reasons.
> I've been through denial and anger and there's no point bargaining.
> I'm going to try to make depression as short as possible...
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the Concurrency-interest