Re: TSX lock elision for glibc v10

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2013-06-13 at 22:08 +0200, Andi Kleen wrote:
> > It seems the intent of this patch is to work around the issue by never
> > using elision unless it's explicitly requested. However, if I'm not
> > mistaken, there's an environment variable to request elision by
> > default, and this would DANGEROUSLY break applications using
> 
> The "danger" being the enforced deadlock not happening ?
> 
> Sorry this whole thing seems like a red herring to me. Even Torvalds
> agreed that it is more a bug in the POSIX standard, than anything else.

Which comment are you referring to?

> Obviously it is.
> 
> Only requiring opt-in would kill a lot of the benefits from 
> putting this into glibc.  Disabling any nesting would also kill a lot of the
> benefit.

This is not about opt-in, nor about killing nesting.  You do need to
recompile, but that's it.
If we don't break the semantics, having the env var to enable elision by
default is much more likely to be accepted (have a look at the env var
discussion please...).

> We could ask the POSIX comittee for a clarification, but that would
> just prevent any chance of getting the feature in 2.18 and get
> some real testing.

IIRC, Rich suggested this to you a few months ago already.

> If we do some real testing and find a real program that is not
> completely broken and is affected by this we can reconsider.

That's not how you can treat a standard, in general.  An explicit opt-in
for experimentation (modulo the env var rules under discussion vs.
configure-time option) that breaks the semantics would be okay with me,
but it's not the important part here, IMO: Important is that we can
safely enable it by default without breaking semantics, so that we can
actually get some widely applicable testing done.

> But I consider this unlikely.

Well, good for you, but whether you or I find this unlikely or likely
doesn't really matter here :)
Seriously, we'd have to hear from either the Austin Group or the
distributions or similarly large user groups that they wouldn't care.

> If you want to break elision completely please do it in your own libc
> only.  Thanks.

The funny thing is that Rich could tell you basically the same thing :)
So, this kind of argument doesn't give us any progress.

I would suggest to get in those pieces that we actually have consensus
for in the project, even if this means that we don't get everything that
you want to contribute into 2.18.