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: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <ak at linux dot jf dot intel dot com>
- Cc: 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 18:16:38 +0200
- Subject: Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- References: <20130624232607 dot GT6123 at two dot firstfloor dot org> <51C9B7D0 dot 5000207 at redhat dot com> <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>
On Wed, 2013-06-26 at 08:51 -0700, Andi Kleen wrote:
> > No, I'm not. First, I said that *if* you want to add new lock types,
>
> I cannot deal with hypotheticals. Please make only concrete and
> implementable suggestions.
Sorry for discussing anything beyond the current step.
> > you should target the C++11 semantics. That doesn't mean that we do add
> > new lock types now. Second, performance hints don't require new
> > semantics (ie, new types); I said that any elision flags that we might
> > have should be performance hints (ie, don't change semantics). That
> > still doesn't say that we have consensus for any interface for making
> > per-lock performance hints.
>
> If elision is disabled as default, there needs to be some way
> to enable it per lock. So an enable bit is needed.
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, given that there's no consensus for how to expose
such a bit.
> If elision is enabled by default, there needs to be some way to disable
> elision. So a disable bit is needed.
Likewise. Note that if we get consensus for the tuning env vars (sorry
for this hypothetical statement), we can effectively disable elision by
using tuning parameters that use elision rarely.
> That is what I have. I don't see how I can make it any simpler.
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.
> 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 then likely not part of the 90%, or is it?
> So there needs to be at least some way to enable this.
*If* we want to have those features in the first round.
> > > As for HLE vs RTM semantics, I consider nested trylock undefined
> > > with elision.
> >
> > I don't understand this sentence. Undefined from which/whose point of
> > view?
>
> The recursive semantics of the elided lock (be it either a type or a flag) is
> undefined. That's similar to DEFAULT.
But you apply this to mutexes that are not DEFAULT mutexes. So it does
affect semantics, and the flags are not just a performance hint.