Re: Lock elision problems in glibc-2.18

[Dominik Vogt <vogt at linux dot vnet dot ibm dot com>]

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.)

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany