[PATCHv3] PowerPC: Fix a race condition when eliding a lock
Adhemerval Zanella
adhemerval.zanella@linaro.org
Wed Sep 2 12:46:00 GMT 2015
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?
More information about the Libc-alpha
mailing list