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: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT


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


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