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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Cc: triegel at redhat dot com, libc-alpha at sourceware dot org, munroesj at linux dot vnet dot ibm dot com
- Date: Mon, 24 Aug 2015 15:42:03 -0400
- 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> <55DB6950 dot 5030805 at redhat dot com> <55DB7040 dot 8060905 at linaro dot org>
On 08/24/2015 03:28 PM, Adhemerval Zanella wrote:
>
>
> On 24-08-2015 15:58, Carlos O'Donell wrote:
>> On 08/24/2015 02:11 PM, Tulio Magno Quites Machado Filho wrote:
>>> Changes since v2:
>>> - Moved part of the source code comments to the commit message.
>>> - Added O'Donnel's suggestion to the source code comments.
>>>
>>> Changes since v1:
>>> - Improved commit message.
>>> - Added new comments in the source code alerting to the concurrency details
>>> intrinsic to this code.
>>> - Removed compiler barriers from this patch, which will be treated in another
>>> patch and will be synchronized with the GCC implementation.
>>
>>> + if (__builtin_tbegin (0)) \
>>> + { \
>>> + if (is_lock_free) \
>>> + { \
>>> + ret = 1; \
>>> + break; \
>>> + } \
>>> + __builtin_tabort (_ABORT_LOCK_BUSY); \
>>> + } \
>>> + else \
>>> + if (!__get_new_count(&adapt_count)) \
>>> + break; \
>>
>> Toravld still suggests an atomic_load_relaxed here:
>> https://www.sourceware.org/ml/libc-alpha/2015-08/msg00893.html
>>
>> Is there any technical objection to that request?
>>
>> It does highlight, as he notes, the transactional and non-transactional
>> accesses for that evaluated value.
>
> No 'technical' objections, only that the transaction idea is exactly to
> avoid the use of atomic accesses altogether. For relaxed accesses it
> won't change anything, but if the idea is to highlight every access
> within transaction with atomics, it might be case where the algorithm
> will require another semantic (like a acquire or release) and it will
> require to drop the atomic usage to avoid generate subpar code.
I'll respond to Torvald and ask him to explain in more detail.
Cheers,
Carlos.