[concurrency-interest] AtomicReference.updateAndGet() mandatory updating
gil at azul.com
Thu Jun 1 11:19:09 EDT 2017
Sent from my iPad
> On Jun 1, 2017, at 5:31 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> 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.
I think the property is that a failing CAS is strictly after the store that failed it, period. Regardless of whether or not that store was volatile. E.g. The CAS-failing store could be Plain, and it may be separately established to be strictly after some other operation (e.g. it may be conditional on the result of a Volatile or Acquire read of some other field), which would establish that the CAS is strictly after that "other operation" even if nothing else does.
Unfortunately (assuming I'm right in the above paragraph), I think the discussion of the Access modes in the proposed javadoc paragraph is not enough to relay this property if it is only coupled with a simple "each CAS is atomic and in the total synchronization order, whether it succeeds or fails." statement.
> 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?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest