This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Optimize libc_lock_lock for MIPS XLP.
On 15/06/2012, at 2:44 PM, Chris Metcalf wrote:
> On 6/14/2012 9:20 PM, Maxim Kuvyrkov wrote:
...
>> As I read it, in case of a contended lock __lll_lock_wait will reset the value of the lock to "2" before calling lll_futex_wait(). I agree that there is a timing window in which the other threads will see a value of the lock greater than "2", but the value will not get as high as hundreds or billions as it will be constantly reset to "2" in atomic_exchange in lll_lock_wait().
>>
>> I do not see how threads will get into a busywait state, though. Would you please elaborate on that?
>
> You are correct. I was thinking the that the while loop had a cmpxchg, but
> since it's just a straight-up exchange, the flow will be something like:
>
> - Fail to initially call lll_futex_wait() if the lock is contended
> - Fall through to while loop
> - Spin as long as the lock is contended enough that *futex > 2
> - Enter futex_wait
>
> So a little busy under high contention, but probably settles out reasonably
> well.
Exactly. I will include the above scenario in the comment to make it more transparent.
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics