This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Current elision proposal
- From: Rich Felker <dalias at aerifal dot cx>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Andi Kleen <ak at linux dot jf dot intel dot com>, Torvald Riegel <triegel at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 26 Jun 2013 16:19:45 -0400
- Subject: Re: Current elision proposal
- References: <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> <20130626191958 dot GG6123 at two dot firstfloor dot org>
On Wed, Jun 26, 2013 at 09:19:58PM +0200, Andi Kleen wrote:
>
> After some private discussion, here's a new proposal:
>
> - Keep the new NORMAL type, semantics as discussed earlier,
> plus compat code.
Many things were discussed, so can you clarify? Will there be a
separate DEFAULT type? Which one will keep the old number?
> - Eliminate the NO_ELISION_NP flag bits, as for TIMED they
> are redundant with NORMAL. The main drawback is that we cannot
> express ADAPTIVE with no elision.
> So that means NORMAL now means "NOT ELIDED"
>
> - Eliminate ELISION_NP too, instead add a new
> pthread_mutexattr_setelision_np() that enables/disables elision for a
> given mutex. This will be a separate patch.
Would this change semantics for non-default mutex types? I think
"setelision" is a misleading name if there is another actual
_semantic_ effect of the attribute change and not just performance
effects.
It might not be a bad idea to be able to have a "setelision" function,
but its states should be "inhibit elision" or "use elision if
possible", not "force elision when it doesn't match the mutex type's
semantics". To get these additional cases, you should also need a new
mutex type, e.g. something like "RECURSIVE_RELAXED"...
Rich