Re: BZ 20822 :powerpc: race condition in __lll_unlock_elision

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2016-11-22 at 11:52 +0100, Florian Weimer wrote:
> 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).

Lock elision relies on this kind of mixed access.  While it would be
nice to have a common formal model for the various HTMs out there from
the perspective of a C11/C++11 memory model setting, I don't think it's
a big problem right now that we don't (AFAIK) have such a formal model.
Lock elision should be well understood, so I'm not worried about any
surprises regarding this use case.