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

[Torvald Riegel <triegel at redhat dot com>]

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.