This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Current elision proposal


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]