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 08:51:30 -0700
- 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>
> 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.
> 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.
If elision is enabled by default, there needs to be some way to disable
elision. So a disable bit is needed.
That is what I have. I don't see how I can make it any simpler.
I'm sure there are lots of ways to make it more complex.
I overloaded the enable bit with enabling nesting on trylock.
I did that to minimize the size of the new API. If people
prefer to have it a separate bit (or type) I'm also ok with that.
I originally defaulted any elided lock acting like a recursive lock,
but people didn't like it, so the default doesn't nest trylock.
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 there needs to be at least some way to enable this.
> > 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.
>
> > So whether it acts like HLE and RTM is undefined.
>
> Do you mean "HLE *or* RTM"? What does "it" refer to?
Yes or. It is the elided lock type/flag.
>
> > In terms of hardware HLE will never nest as deeply as RTM can,
> > because each nesting level needs hardware resources (a lock buffer)
> > So it's unlikely HLE will ever nest as deep as RTM can.
>
> So? Maybe HLE won't work for long chains of hand-over-hand locking, but
> it would be reasonable to assume that it works for a few nested critical
> sections, right?
I assume there will be always software with deeper nesting than what
reasonable hardware can provide. Software is getting more complex all
the time too.
-Andi