This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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 07/11/2012 09:53 AM, Maxim Kuvyrkov wrote:
> 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.

Maybe the thread ends its time slice and gets interrupted.  There
aren't any guarantees.

> 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)
> +      ;

This is a much better idea than an unbounded spin.

Andrew.


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