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

Justin Sampson jsampson at guidewire.com
Mon May 29 13:57:17 EDT 2017

Gil Tene wrote:

> The recent discussion here is focused on whether a relaxing of the memory
> ordering semantics of compareAndSet, from the volatile write semantics
> being unconditional to being conditional (on the write actually occurring) is
> advisable. The claim is that there is existing Java software out there that
> may rely on the existing unconditional definition for correctness, and that
> relaxing the definition will break such software. Examples of how the
> conditional/unconditional behavior difference can be observed by a
> concurrent algorithm were given (I believe) as proof that such software
> can (and likely does) exist.

Thank you for your helpful definitions. As for examples, yes, Alex gave an
example of a racy program that relies on the unconditional volatile write
semantics of a strong CAS. I also gave examples of existing CAS methods in
j.u.c.atomic that do not have this property, so we know for certain that
JDK implementers have not had a consistent understanding of it being
required, even though it does seem pretty clear in the JDK 8 docs. That
leads me to presume that I shouldn't rely on that property being provided
by the various native implementations across platforms -- which is okay
with me because I've personally never _needed_ to rely on it -- but that
does cause problems for programs like Alex's.


More information about the Concurrency-interest mailing list