Re: BZ 20822 :powerpc: race condition in __lll_unlock_elision

[Florian Weimer <fweimer at redhat dot com>]

On 11/22/2016 10:41 AM, Torvald Riegel wrote:

> > And unlike code
> > using incorrect synchronization or legacy atomics, we don't have a path
> > towards the C11 model because what the code does is completely outside
> > it, so there's no argument on favor of gradual/partial conversion.
>
> The HW transaction has to synchronize with nontransactional code.  We're
> obviously going to use the C11 model for nontransactional code.  Thus,
> it cannot be unrelated.  It's true that we don't have a detailed
> description of how HW transactions *extend* the C11 model, but it
> clearly would be an extension because it simply has to fit in there and
> it will use the same underlying mechanisms.
>
> One can also think about it this way: There is nontransactional code
> that has to use atomics (because there are concurrent accesses from
> other nontransactional code as well as transactional code).  So we are
> going to use atomics there.  Then, even if just for consistency, we're
> going to use (relaxed MO) atomic accesses too for all other concurrent
> accesses to the same data.

The counter-argument to that this is until we have a specification of 
how this kind of transactional memory works, we don't know what it means 
if an object is accessed from both a transaction and and other 
non-transactional code, and what external constraints are needed to make 
such access valid (if any).  There are some really scary examples from 
early transaction memory implementations.

But come to think of it, the core issue hasn't got to do much with 
atomics at all.  It's just about how the transactional memory 
implementation works.  So I don't really have any strong opinions here.

Thanks,
Florian