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: Torvald Riegel <triegel at redhat dot com>
- To: Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm 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
- Date: Thu, 08 Oct 2015 17:43:32 +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>
Sorry for the very long response time. I've been sick since a while and
am slow in catching up.
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.