[concurrency-interest] AtomicReference.updateAndGet() mandatory updating
oleksandr.otenko at gmail.com
Thu Jun 1 05:35:14 EDT 2017
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 code I know of can be fixed in fairly straightforward ways, but you’d need to ease the introduction of this change of behaviour.
There may be more code that unwittingly relies on such behaviour, because many people see compareAndSet as a way to abstract away x86 LOCK:CMPXCHG - without reading too much what such abstraction means on other platforms.
> On 1 Jun 2017, at 02:29, Martin Buchholz <martinrb at google.com> wrote:
> On Wed, May 31, 2017 at 5:06 AM, Doug Lea <dl at cs.oswego.edu <mailto:dl at cs.oswego.edu>> wrote:
> On 05/31/2017 07:03 AM, Doug Lea wrote:
> >> C++ clearly specifies "CAS classic". There is no way to specify
> >> release semantics for a failed CAS, since there is no write.
> > The current C++ spec, sec 29.2 includes versions that do so,
> Except that memory_order_release is specifically disallowed.
> Not that it matters, since the question at hand is about
> The fact that memory_order_release is specifically disallowed "proves" that Hans is right that this is referring to the semantics of the read alone.
> Please please make the semantics of CAS in Java as close as possible to C++. In particular, don't make them more expensive for no good reason.
> The volatile read in CAS failure alone ensures that the CAS is a sequentially consistent synchronization action (part of the total order of all such actions).
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest