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: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- 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 18:32:25 +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> <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> <55DC7E7D dot 8040602 at linaro dot org>
On Tue, 2015-08-25 at 11:41 -0300, Adhemerval Zanella wrote:
>
> 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.
Agreed current HTMs are almost always best-effort, but I don't think a
relaxed-MO atomic should abort a txn.
>
> >
> >> 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.
Agreed.
> Anyway, I do see the value of making atomic access using atomic api
> insides transactions and we can handle futures cases in specific cases.
Good.