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: Andi Kleen <ak at linux dot jf dot intel dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Andi Kleen <ak at linux dot jf dot intel dot com>, Rich Felker <dalias at aerifal dot cx>, 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 10:37:10 -0700
- Subject: Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- References: <20130625170656 dot GB6123 at two dot firstfloor dot org> <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>
> 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'm not sure what you really mean with consensus, here, like a vote or what?
> We can not include this feature in the first round, gather feedback
> using the 90% that we do cover with what can agree on now, and then use
> that feedback to decide what we do in the second round.
In terms of elision evaluation something that cannot be enabled/disabled
is not 90%. It's near useless in terms of getting feedback imho.
> > The use case of nesting for trylock is imho
> > important because it seems to be a common (even if poor) use case to
> > use trylock as a spin frontend for pthread_mutex_lock().
> > If people do that, they could never nest their locks with elision.
>
> So if it's a poor use case, why should we target it in the first round?
It's not the best general way to write a spinlock, but it's still
better than the alternatives. But more importantly people do it in
practice in existing source.
> It's then likely not part of the 90%, or is it?
I don't know what that means.
>
> > 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.
-Andi
--
ak@linux.intel.com -- Speaking for myself only