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: Torvald Riegel <triegel at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org, munroesj at linux dot vnet dot ibm dot com
- Date: Tue, 25 Aug 2015 11:41:01 -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> <55DB7040 dot 8060905 at linaro dot org> <1440502472 dot 27492 dot 138 dot camel at localhost dot localdomain>
On 25-08-2015 08:34, Torvald Riegel wrote:
>
> No. The rule I'd like to follow is that if we need atomic accesses to a
> memory object somewhere in the code base, that we then consistently use
> atomic accesses for all accesses to this object (with the exception of
> initialization code, where things like memset can be simpler).
>
> Thus, if you use just transactions to prevent data races for an object,
> no atomics are required. This holds for the vast majority of objects
> accessed in transactions (except lock implementations and such).
>
> IMO, not using atomics for accessing is_lock_free in the txn creates an
> exception in our rules, and given that there's no problem to used an
> MO-relaxed access there, it's just easier to avoid creating an
> exception. And it makes it possible to use an atomic type for it in the
> future.
The problem I see it all hardware transactional either do not explicit
guarantee progress forward for transactional code or require a fallback
code for performance reason, and then non-transactional code would be
required.
>
>> 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 don't quite understand what you mean, sorry.
>
And what I am trying to avoid is to require some atomic access in a non
MO-relaxed way in a transactional just to follow the atomic access rule.
Anyway, I do see the value of making atomic access using atomic api
insides transactions and we can handle futures cases in specific cases.