[PATCHv3] PowerPC: Fix a race condition when eliding a lock

[Paul E. Murphy]

[Adding Andi if he has an opinion]

On 10/08/2015 10:54 AM, Torvald Riegel wrote:
>> A busy lock likely indicates contention in the critical section which
>> does not benefit from elision, I'd err on the side of a persistent
>> failure.
> 
> I don't think I agree.  An already-acquired lock is something that could
> be hit less likely by using elision more often on this lock (think about
> the "lemming effect").
> 

My line of thinking is that you are already experiencing the effect if
a thread hits a taken lock. It most likely [1] implies adapt_count > 0,
so you are guaranteed a time period of serialization. The best outcome is
that you manage to run a transaction in between an actual lock. The worst
being you extend the serialization period.

I think perhaps the best of both worlds might be to check the lock, and
set the persistent bit if the lock is busy with waiters. Thoughts?

[1] A pthread condition waiter is an odd exception in that they will set
the lock to busy with waiters when they wake up using an elidable lock,
but not set adapt_count. Also, you could hit the case where adapt_count
goes from 1 -> 0.