[aarch64-port-dev ] openjdk atomics
    Andrew Haley 
    aph at redhat.com
       
    Tue Feb 11 09:42:10 PST 2014
    
    
  
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