[aarch64-port-dev ] openjdk atomics

Andrew Haley aph at redhat.com
Thu Feb 13 03:35:19 PST 2014


I'm going to do this.  I'd like to make a release of this port but I
think we have do fix this first.

Andrew.


On 02/11/2014 05:42 PM, Andrew Haley wrote:
> On 02/11/2014 04:23 PM, Andrew Dinn wrote:
>> On 11/02/14 16:06, Andrew Haley wrote:
>>> 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.
>>
>> Well, it's not that difficult to determine.
> 
> Well, yes it is.  You'd have to determine how the Store{LI}Conditional
> and CompareAndSwap{ILNP} are used in order to determine whether the
> barriers are needed.
> 
>> There are explicit lock/unlock instrctions in aarch64.ad (FastLock,
>> FastUnlock) where we currently call the assembler method cmpxchgptr. In
>> these cases we shouldn't need to do a full dmb.
> 
> That's right.
> 
>> We also have other rules which may well require a full dmb
>> (Store{LI}Conditional, CompareAndSwap{ILNP}).
> 
> That's also right.
> 
>> So, perhaps we need to implement two variants here.
> 
> Yes,
> 
> Andrew.
> 



More information about the aarch64-port-dev mailing list