This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Unify pthread_spin_[try]lock implementations.


On 11/07/2012, at 8:44 PM, Andrew Haley wrote:

> On 07/11/2012 09:25 AM, David Miller wrote:
>> From: Roland McGrath <roland@hack.frob.com>
>> Date: Wed, 11 Jul 2012 01:14:41 -0700 (PDT)
>> 
>>>> +int
>>>> +pthread_spin_lock (pthread_spinlock_t *lock)
>>>> +{
>>>> +  while (atomic_compare_and_exchange_val_acq (lock, 1, 0) != 0)
>>>> +    while (*lock != 0)
>>>> +      ;
>>> 
>>> What's the inner loop for?
>> 
>> I guess the idea is to spin with non-atomic reads when the lock is
>> contended so we don't do expensive bus cycles grabbing the cache line
>> in exclusive state over and over again.
>> 
>> If we spun using only the atomic it would be very expensive.
> 
> Sure, but on ARM at least there's no guarantee that the local processor
> will see changes to the state of the lock when another processor frees
> it.

Hm, but this is exactly what ARM port does and did for a while.  I guess the memory on the local processor eventually gets updated and the loop breaks.

This is an interesting point and maybe introducing a counter like below will improve spinlocks for ARM.

+  int counter = 123456;
+  while (atomic_compare_and_exchange_val_acq (lock, 1, 0) != 0)
+    while (*lock != 0 && --counter)
+      ;

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]