[concurrency-interest] AtomicReference.updateAndGet() mandatory updating

Andrew Haley aph at redhat.com
Fri May 26 11:36:20 EDT 2017


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.

> Basically, there is no StoreLoad ordering [that is required to be]
> enforced on the hardware by a store release, which makes it
> insufficient.

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 mailing list