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: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, 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 16:28:00 -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> <55DB6950 dot 5030805 at redhat dot com>
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.
>
> Cheers,
> Carlos.
>