This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]