[aarch64-port-dev ] openjdk atomics

[Andrew Dinn]

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.

When taking a lock (i.e. entering a critical section) the ldaxr ensures
that the locker see any writes committed by some other thread which
previously owned the lock. The stlxr ensures that the locking thread
commits any prior writes as part of obtaining the lock. Store operations
in this thread may speculate past the ldaxr but they will not speculate
past the stlxr and, since they *will* not refer to the lock word this
makes no difference.

When clearing a lock a simple release store (stlr) can be used to ensure
that writes made in the critical section are published and visible i.e.
it provides the other half of the contract met by the ldaxr.

This seems to me to be rather like the case where volatile reads and
writes can be done with just an ldaxr and a stlxr. So long as all
threads do the same then every ldaxr guarantees to see the latest
changes to the volatile because they were published using stlxr.

regards,


Andrew Dinn
-----------
Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Paul Hickey (Ireland)