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

[Torvald Riegel <triegel at redhat dot com>]

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.