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: Mon, 19 Oct 2015 12:01:41 -0200
- 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> <1444319012 dot 25110 dot 210 dot camel at localhost dot localdomain>
Torvald Riegel <triegel@redhat.com> writes:
> Sorry for the very long response time.
Please do not. You have been helping me a lot here. ;-)
> I've been sick since a while and am slow in catching up.
I hope you're better now.
> On Wed, 2015-08-26 at 13:31 -0300, Tulio Magno Quites Machado Filho
> wrote:
>> 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 suggest instead:
>
> The evaluation of the macro expression is_lock_free encompasses one or
> more loads from memory locations that are concurrently modified by other
> threads. For lock elision to work, this evaluation and the rest of the
> critical section protected by the lock must be atomic because an
> execution with lock elision must be equivalent to an execution in which
> the lock would have been actually acquired and released. Therefore, we
> evaluate is_lock_free inside of the transaction that represents the
> critical section for which we want to use lock elision, which ensures
> the atomicity that we require.
>
>
> If you think this is adequate, please commit.
LGTM.
I will commit.
Thanks again!
--
Tulio Magno