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

Doug Lea dl at cs.oswego.edu
Tue May 30 10:06:47 EDT 2017


Catching up...

On 05/26/2017 04:08 PM, Nathan and Ila Reynolds wrote:
>> "The memory effects of a write occur regardless of outcome."
>> "This method has memory effects of at least one volatile read and write."
> 
> I am not sure what memory effects means.  If this is defined somewhere
> in the specs, then ignore this since I haven't read JDK 9 specs.

Thanks; it would be better to say:
"The memory consistency effects of a write occur regardless of outcome."

About the controversy surrounding ARM mappings for Volatile-mode CAS:
The main underlying intent is to ensure that Volatile mode operations
act atomically and as if globally totally ordered wrt each other.
With single instruction CAS (as on x86 etc), this is easy to arrange.
Plus there are cases like CAS of thread-confined variables in which,
in principle they could be optimized to conditional stores; plus other
similar weakenings. In the absence of weakening, when emulated using
ARM/POWER LL/SC, this further interacts with whether implementations
use trailing-fence vs leading-fence conventions. If using trailing
fence (which most if not all Java implementations do), then it seems
that the only good decision is to issue a fence on comparison failure;
perhaps differently depending on whether using AArch64 LDAX/STRX
vs explicit fences inside CAS loop.

At least some C/C++ ARM and POWER mappings use leading-fence
convention, which could lead to differences here. Also, there
are version of C++ compare_exchange_strong that take a second
memory_order argument controlling the consistency effects on
failure (by default seq_cst/volatile). Although implementations
elide fence here only on comparison failure, not on contention
failure. There's no Java equivalent, so people would need to
use one of the weak variants and add fences.

-Doug




More information about the Concurrency-interest mailing list