[concurrency-interest] AtomicReference.updateAndGet() mandatory updating
dl at cs.oswego.edu
Thu Jun 1 08:25:48 EDT 2017
OK, I now see that we should try to solve this in some other way...
On 06/01/2017 05:35 AM, Alex Otenko wrote:
> There is code that relies on the CAS behaving like a volatile store
> always. This interpretation is based on direct question “does CAS always
> behave like a volatile store” to the people working on JVM, not plain
> reading of javadoc. It very likely predates C++ spec.
The statement about CAS acting as both volatile load and store was
the best anyone could come up with in terms of JSR133 spec (which
does not cover CAS).
But the main underlying requirements are that each CAS is atomic and
in the total synchronization order, whether it succeeds or fails.
(This is for regular volatile CAS, not the new weaker variants.)
Maybe we should just say this.
It still implies the main property that Alex has been getting at:
"A failing CAS is strictly after the (volatile) store that failed it."
But does so without explicitly claiming that a failed CAS
has volatile write semantics.
And further implies that Alex's example still holds.
And for ARM, if ldax is used for load, then no fence on failure seems
to be required?
More information about the Concurrency-interest