This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- From: Rich Felker <dalias at aerifal dot cx>
- To: Andi Kleen <ak at linux dot jf dot intel dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, Andi Kleen <andi at firstfloor dot org>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 26 Jun 2013 16:15:00 -0400
- Subject: Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- References: <20130625173203 dot GL29800 at brightrain dot aerifal dot cx> <20130625204013 dot GS5643 at tassilo dot jf dot intel dot com> <1372197850 dot 964 dot 9938 dot camel at triegel dot csb> <20130626003555 dot GT5643 at tassilo dot jf dot intel dot com> <1372235629 dot 964 dot 10004 dot camel at triegel dot csb> <20130626145934 dot GU5643 at tassilo dot jf dot intel dot com> <1372260495 dot 22198 dot 149 dot camel at triegel dot csb> <20130626155130 dot GV5643 at tassilo dot jf dot intel dot com> <1372263398 dot 22198 dot 260 dot camel at triegel dot csb> <20130626173710 dot GW5643 at tassilo dot jf dot intel dot com>
On Wed, Jun 26, 2013 at 10:37:10AM -0700, Andi Kleen wrote:
> > You only need that if you want to allow programs to enable it, *per
> > lock*. I don't see why it's absolutely necessary to have this feature
> > in the first round,
>
> So that applications can enable it when it's disable or disable
> when it's enabled, so that they can do useful evaluation.
>
> > given that there's no consensus for how to expose
> > such a bit.
>
> Well I need it. Do you have a counter proposal?
I think what the others have been saying is that the first round of
testing, in a public release, could take place with just the env vars
for tuning. This does not mean there won't be new ways of tuning
individual locks in the future, but adding new interfaces, which
consume precious bits in the already-tight mutex and mutex attr
structures, and which glibc must commit to keeping FOREVER, needs more
attention. The hope is that we can get the parts of this patchset
which do not lock glibc into permanently committing to particular APIs
(which might turn out not to be the best ones) committed for the
release so that people can begin testing elision, and then once it
starts getting some heavier testing and feedback on what users want
and what works well, we can finalize the other patches. And of course
in the meantime you're free to do all the internal testing you want,
or to point others to your published patches.
> > > So there needs to be at least some way to enable this.
> >
> > *If* we want to have those features in the first round.
>
> Not having any tuning capability is a show stopper for me.
The first-round tuning should be the env var approach, I think.
And nothing called "tuning" should ever alter semantics.
Rich