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

Alex Otenko oleksandr.otenko at gmail.com
Thu Jun 1 12:01:14 EDT 2017


The point about guaranteeing a particular order of a volatile load after a volatile store that failed the CAS is that through such ordering a synchronize-with edge is added to the happens-before order as well. If the store is not volatile, there is no mechanism in JMM that would guarantee non-volatile loads after failing CAS to observe something before any other store except earlier volatile stores to the variable the failing CAS was accessing.

Without the edge non-volatile stores may be observed by non-volatile reads, but also maybe not. With the edge there is no option to not observe the stores.

If we claim only total ordering, but not that CAS is a volatile load, it doesn’t imply a synchronize-with edge.

If we claim the total ordering, and that CAS is a load and a store, but not that they are necessarily volatile, it doesn’t imply a synchronize-with edge.


It seems Doug’s version mentioned both. My only question is about ambiguity: does “(volatile)” mean “volatile or not”, or “which of course is volatile”.


Alex


> On 1 Jun 2017, at 16:19, Gil Tene <gil at azul.com> wrote:
> 
> 
> 
> 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?
>> 
>> -Doug
>> 
>> 
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170601/0f3c77b1/attachment.html>


More information about the Concurrency-interest mailing list