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

[Tulio Magno Quites Machado Filho]

Ping x3, Torvald.  ;-)

Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com> writes:

> Ping x2.
>
> "Tulio Magno Quites Machado Filho" <tuliom@linux.vnet.ibm.com> writes:
>
>> Ping, Torvald.
>>
>>
>> "Tulio Magno Quites Machado Filho" <tuliom@linux.vnet.ibm.com> writes:
>>
>>> Torvald Riegel <triegel@redhat.com> writes:
>>>
>>>> On Tue, 2015-08-25 at 19:08 -0300, Tulio Magno Quites Machado Filho
>>>> wrote:
>>>>> Torvald Riegel <triegel@redhat.com> writes:
>>>>> 
>>>>> > On Mon, 2015-08-24 at 15:11 -0300, Tulio Magno Quites Machado Filho
>>>>> >> +   threads, either during lock acquisition, or elision.  In order to avoid
>>>>> >> +   this evaluation from becoming a data race the access of is_lock_free
>>>>> >
>>>>> > It could be a data race because you're not using atomics there, but
>>>>> > that's not the whole point.  (We use the term "data race" specifically
>>>>> > to refer to the C11/C++11 memory model concept of the same name.)
>>>>> > You want to ensure the lock elision synchronization scheme, and thus are
>>>>> > moving it inside the txn.
>>>>> 
>>>>> Are you complaining about the usage of the term "data race"?
>>>>
>>>> Yes.
>>>>
>>>>> If so, what about "race condition"?
>>>>
>>>> Well, that would be better, but a race condition is not necessarily a
>>>> bad thing.  It's usually better to say which execution or interleaving
>>>> you need to avoid, than just saying "race condition".
>>>
>>> What about the following?
>>>
>>> /* CONCURRENCY NOTES:
>>>
>>>    The macro expression is_lock_free is read and possibly written to by
>>>    multiple threads, either during lock acquisition, or elision.  In order to
>>>    avoid this evaluation from becoming a race condition with the lock
>>>    acquirement from the lock primitive, the access of is_lock_free is placed
>>>    *inside* the transaction.  Within the transaction we are assured that all
>>>    memory accesses are atomic and is_lock_free can be evaluated with relaxed
>>>    memory order.  That way, the value of is_lock_free is consistent with the
>>>    state of the lock until the end of the transaction.  */
>>
>> Anything else you'd like to change before I push this?
>>
>> Thanks,

-- 
Tulio Magno