[aarch64-port-dev ] openjdk atomics

[Andrew Haley]

On 02/11/2014 03:53 PM, Andrew Dinn wrote:
> On 11/02/14 14:58, Andrew Haley wrote:
>> It's worse than that because cmpxchg (AKA cas) is the primitive that's
>> used almost everywhere, and it needs a barrier at each end to make
>> sure that memory operations aren't speculated after the ldxr:
>>
>> 	dmb	ish		// Full barrier
>>
>> 1:	ldxr	%1, %2
>> 	cmp	%1, %3
>> 	b.ne	2f
>> 	stxr	%w0, %4, %2
>> 	cbnz	%w0, 1b
>> 2:
>> 	dmb	ish		// Full barrier
> 
> Hang on, I don't follow this. Why do we need to do anything more than
> substitute an ldaxr and stlxr pair here in order to implement Java
> locking/synchronization.

This isn't about locking/synchronization, it's about CAS.

This is what we do at the moment:

	<Access [A]>

	// atomic_op (B)
1:	ldaxr	x0, [B]		// Exclusive load with acquire
	<op(B)>
	stlxr	w1, x0, [B]	// Exclusive store with release
	cbnz	w1, 1b

	<Access [C]>

It doesn't forbid orderings such as

Load [B] -> Load [C] -> Store [A] -> Store [B]

It may be that this doesn't matter, but I would surely prefer to have a
CAS that didn't have this property, and I'm sure we're in no position
to audit all of C2 to make sure that it doesn't matter.

Andrew.