This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: BZ 20822 :powerpc: race condition in __lll_unlock_elision
- From: Torvald Riegel <triegel at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: munroesj at linux dot vnet dot ibm dot com, Rajalakshmi Srinivasaraghavan <raji at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org, aaron Sawdey <acsawdey at linux dot vnet dot ibm dot com>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>, Steve Munroe <sjmunroe at us dot ibm dot co>, carlos at redhat dot com, adhemerval dot zanella at linaro dot org, adconrad at ubuntu dot com, wschmidt at linux dot vnet dot ibm dot com
- Date: Tue, 22 Nov 2016 14:45:46 +0100
- Subject: Re: BZ 20822 :powerpc: race condition in __lll_unlock_elision
- Authentication-results: sourceware.org; auth=none
- References: <f777eebe-4a7b-87d2-1281-ab605c7fce8b@linux.vnet.ibm.com> <1479394010.7146.1154.camel@localhost.localdomain> <1479771736.9880.42.camel@oc7878010663> <1479804279.7146.1280.camel@localhost.localdomain> <a5e57060-b0e0-3156-5fdd-da24a4447a5d@redhat.com> <1479807670.7146.1295.camel@localhost.localdomain> <e649d9d8-1711-fa6b-b075-7dfdaf0c18d4@redhat.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.