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

[Paul E. Murphy]

On 09/01/2015 04:58 PM, Adhemerval Zanella wrote:

>> I'm not convinced any of the existing codes should be non-persistent:
>>
>> A pthread_mutex_trylock attempt within an elided pthread_mutex_lock is
>> guaranteed to fail try_tbegin times if there is no contention on the lock.
>> Aborts get increasingly expensive as you increase the amount of speculative
>> execution.
>>
>> 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 do not that much information to decide it, although I do see for pthread_mutex_t 
> at least the _ABORT_LOCK_BUSY is not persistent if the critical region does not 
> generate enough contention.

This seems to violate my understanding of the adaptive algorithm. I agree, there
is a possibility another thread might successfully elide while adapt_count != 0,
*futex == 0, and it happens to be within the retry loop.

Transactions are not free. The question is: Is it cheaper to risk a few more
failures in hopes of the transaction succeeding, or just grabbing the lock?

This becomes less desirable with increasing values of try_tbegin. I've found
11 to be the value which factors out the "false" failures under SMT8.