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

["Tulio Magno Quites Machado Filho" <tuliom at linux dot vnet dot ibm dot com>]

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.  */

> I'd still like to see this getting improved eventually, and I'd
> appreciate if you could participate in that.

Ack.  Count me in.

-- 
Tulio Magno