This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCHv3] PowerPC: Fix a race condition when eliding a lock
- From: "Tulio Magno Quites Machado Filho" <tuliom at linux dot vnet dot ibm dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: carlos at redhat dot com, adhemerval dot zanella at linaro dot org, libc-alpha at sourceware dot org, munroesj at linux dot vnet dot ibm dot com
- Cc:
- Date: Tue, 01 Sep 2015 11:00:24 -0300
- Subject: Re: [PATCHv3] PowerPC: Fix a race condition when eliding a lock
- Authentication-results: sourceware.org; auth=none
- References: <55D742D3 dot 9050600 at redhat dot com> <1440439895-11812-1-git-send-email-tuliom at linux dot vnet dot ibm dot com> <1440507739 dot 27492 dot 183 dot camel at localhost dot localdomain> <87oahv9g27 dot fsf at totoro dot lan> <1440578622 dot 30828 dot 40 dot camel at localhost dot localdomain> <871teq6mgh dot fsf at totoro dot lan>
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