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

["Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>]

On 09/02/2015 07:45 AM, Adhemerval Zanella wrote:
> 
> 
> On 01-09-2015 19:43, Paul E. Murphy wrote:
>>
>>
>> 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?
> 
> Well that is exactly the question I do not know it will heavy depend of the
> kind of algorithm and contention you have.
> 
>>
>> 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.
>>
> 
> If the workloads you are trying are showing a higher try_tbegin is better, than
> indeed we can either increase it or set _ABORT_LOCK_BUSY as a persistent failure
> so the algorithm will bail out and use locks instead of retrying.
> 
> Which kind of benchmark or workloads are you using to evaluate it?
> 

I've posted my "workload" examples at git@github.com:pmur/glibc-test-tle.git. Take
them with a grain of salt, and think of them as sanity checks. I've been using
various derivations of them to poke at what I think are edge cases. Any suggestions
or additions are appreciated.