Re: [PATCH] Optimize libc_lock_lock for MIPS XLP.

[Maxim Kuvyrkov <maxim@codesourcery.com>]

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