This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TSX lock elision for glibc v10


On Fri, Jun 14, 2013 at 04:15:04PM +0200, Torvald Riegel wrote:
> > 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.

Note that normal-type mutexes could still use elision as long as they
kill nesting, and default-type mutexes could use it even with nesting.
Old binaries treating default and normal as the same would still get
some of the benefit of elision (for non-nested locks), just not all of
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.

Yes. I am not going to raise the issue with them myself because I
don't believe it's a bug; the standard is clear as written, and the
choice was clearly intentional at the time. If Andi believes the
standard should be changed to meet changing implementation realities
for mutexes, I have no objection to him putting forth this argument
before the standards body to see what others think.

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

It's also dangerous. Once we have set the precedent that "normal-type
mutext semantics might be broken in some glibc versions in some
configurations", application developers will be scared to rely on the
standard semantics. Even if nothing is broken now, we have undermined
confidence in the principle that you can program via the interface
contracts as specified, rather than programming via awareness of
implementation bugs and shortcuts implementors took for performance.
It has taken a LONG time to build that confidence, and we're still not
there, but we're getting there. I do not want to see regressions in
this area.

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

I understand that Andi is strongly in favor of a way to force elision
onto existing binaries, even when it breaks semantics, in order to be
able to do widespread testing (presumably both for bugs and for
performance). What if, instead of a directly tunable environment
variable, we made a (not necessarily permanent) way to override the
default via an LD_PRELOAD library? Basically, what the LD_PRELOAD
library would do is redirect the old symbol versions (which treat 0 as
PTHREAD_MUTEX_NORMAL) to the new ones (which would treat 0 as
PTHREAD_MUTEX_DEFAULT). Of course this could be done with an
environment variable too, but the reasons I prefer LD_PRELOAD is that:

1. It's _automatically_ forbidden under suid without any additional
logic that could contain new bugs.

2. It's widely known and understood that LD_PRELOAD can arbitrarily
break library semantics.

3. Thus, programs stripping dangerous stuff from the environment will
already be stripping LD_PRELOAD, whereas they would not yet know about
the not-yet-existant break-mutex-semantics environment variable.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]