[concurrency-interest] Semantics of compareAndSwapX

Doug Lea dl at cs.oswego.edu
Wed Apr 2 08:50:30 EDT 2014


On 04/02/2014 07:34 AM, Andrew Haley wrote:
> It seems to me that Doug and Hans disagree.
>
> So, I'm going to put this to a vote.

Backing up first. The current specs for CAS say only
(in java.util.concurrent.atomic package docs):

   compareAndSet ... have the memory effects of both reading and writing
   volatile variables.

Conservative mappings for volatiles on AArch64 are
volatile-read : load-acquire.
volatile-write : store-release followed by dmb.

The straightforward mapping for CAS using these is more conservative
than either of your options:

	<Access [A]>
	// atomic_op (B)
1:	ldxar	x0, [B]		// Exclusive load with acquire
	<op(B)>
	stlxr	w1, x0, [B]	// Exclusive store with release
	cbnz	w1, 1b
	dmb	ish		// Full barrier
	<Access [C]>

So if you want to do something uncontroversial
pending further analysis, you could stick with this
and avoid voting for now.

Your two options weaken this in different ways, and
the questions become whether either could detectably
impact any guarantees and whether either could conflict
with any internal openJDK/hotspot assumptions.
And also whether an improved spec for CAS in the style
of C11/C++-11 for revised JMM would matter.

-Doug

>
> Should CAS on Aarch64 be
>
> 	<Access [A]>
>
> 	// atomic_op (B)
> 1:	ldxr	x0, [B]		// Exclusive load
> 	<op(B)>
> 	stlxr	w1, x0, [B]	// Exclusive store with release
> 	cbnz	w1, 1b
> 	dmb	ish		// Full barrier
>
> 	<Access [C]>
>
> or
>
> 	<Access [A]>
>
> 	// atomic_op (B)
> 1:	ldxar	x0, [B]		// Exclusive load with acquire
> 	<op(B)>
> 	stlxr	w1, x0, [B]	// Exclusive store with release
> 	cbnz	w1, 1b
>
> 	<Access [C]>
>
> or something else?
>
> Please reply with your choice.
>
> Thanks,
> Andrew.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



More information about the Concurrency-interest mailing list