Re: Lock elision problems in glibc-2.18

[Torvald Riegel <triegel at redhat dot com>]

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.

Nonetheless, even if the app does not retry forever, it might retry a
smaller or larger number of times.  So even if it is correct and stops
trying to use a transaction eventually, it might retry often -- in which
case we don't have a correctness / forward progress problem but a
performance problem.  To me, the question is whether we'll encounter
this in practice.  If abort codes are ABI, it seems unlikely and we
don't even have a performance problem.  If abort codes can likely be
misinterpreted, then the decision the app faces might be difficult: you
don't want to be super-conservative in how often you retry, but you
don't want to bang your head constantly against a wall either.  So, iff
we encounter such situations in practice, then we'd need to consider
whether we can help avoiding them by doing sth in glibc.

For now, I think we should try to make the abort codes part of an ABI,
and see how things work in practice.