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

[Adhemerval Zanella]

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.