Re: Lock elision problems in glibc-2.18

[Torvald Riegel <triegel at redhat dot com>]

On Mon, 2013-09-16 at 12:25 +0200, Dominik Vogt wrote:
> On Mon, Sep 16, 2013 at 10:58:06AM +0200, Torvald Riegel wrote:
> > On Fri, 2013-09-13 at 23:23 -0700, Andi Kleen wrote:
> > > Torvald Riegel <triegel@redhat.com> writes:
> > > 
> > > >  We need to do this, and if the app
> > > > misinterprets and *always* keeps retrying, it will hang.
> > > 
> > > The app is broken then. Retrying forever is simply not allowed.
> > > I don't think it makes sense to complicate glibc for this.
> > 
> > I agree (at least for the near future), and my preferred solution would
> > be for certain abort codes to be part of an ABI.
> 
> The zEC12 has so called "constrained" transactions that do retry
> until the transaction succeeds.  The hardware make great efforts
> to guarantee that the transactions eventually completes (like
> stopping all other cpus if necessary).  Although this kind of
> transaction is very, very limited in length, run time, memory
> footprint and control flow, it _might_ be possible to call very
> short inlined functions from within a constrained transaction.
> 
> Now, I'm not saying that e.g. calling trylock() from a constrained
> transaction is a problem at the moment (because the limits of
> constrained transactions in the zEC12 are way too strict to call a
> library function, even if linked statically).  But the statement
> (and I am aware that is not what Andi wrote)
> 
>   "an app that always keeps retrying is broken"
> 
> is definitely incorrect.  (In the future the limitations of
> constrained transactions might be pushed so that calling a
> function might be possible.)

If the HTM gives forward-progress guarantees (eg, "constrained" txns)
and the application can control that the transactions it starts never
violate the constraints for those guarantees, then always retrying would
be allowed.  However, glibc doesn't give any guarantees regarding what
it does in its implementation, so if you call trylock(), for example,
you can't rely on "constrained" txns anymore because you don't control
the transaction's code anymore.