This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Current elision proposal
- From: "Carlos O'Donell" <carlos at redhat dot com>
- 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>, Rich Felker <dalias at aerifal dot cx>, libc-alpha at sourceware dot org
- Date: Wed, 26 Jun 2013 17:32:39 -0400
- Subject: Re: Current elision proposal
- References: <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> <20130626173710 dot GW5643 at tassilo dot jf dot intel dot com> <20130626191958 dot GG6123 at two dot firstfloor dot org>
On 06/26/2013 03:19 PM, Andi Kleen wrote:
>
> After some private discussion, here's a new proposal:
>
> - Keep the new NORMAL type, semantics as discussed earlier,
> plus compat code.
I warn you that doing so is an ABI change whose discussion may
consume the rest of the time we have and prevent elision in any
form from going into 2.18.
If you instead create a new internal-only NORMAL type, with no
exposed ABI, this would be immediately acceptable.
I will work up a patch to express to you exactly what I mean.
> - 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"
Agreed.
In that NORMAL implies no elision.
In that DEFAULT (or TIMED_NP) implies elision.
> - 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.
Agreed, but only if the API does not break the semantics of any
of the existing types.
That is to say that if the type is NORMAL, and you call the new
API to enable elision, that the elision is ignored because NORMAL
doesn't support elision. The functions would still return success.
To be clear when I say "semantics" I mean those things guaranteed
by the POSIX API, and the current (and prior) implementations.
> This does not change anything existing, just adds a new symbol.
>
> - (No initializers as before)
OK. I assume you mean "no static initializer."
> - Stop eliding ADAPTIVE, as it's apparently specified as
> "shall deadlock". Add a new ADAPTIVE type longer term
> that allows deadlocking longer term (i guess post 2.18)
Agreed. This was technically a bug in the current implementation.
Agreed that in the future we can look at new types that support
elision explicitly. The more interesting solution is going to
be to use the C++11 semantics for new types. The new C++11 semantics
are elision friendly, backed by the C++11 memory model, and thus
potentially more useful for our users.
Cheers,
Carlos.