This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
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.