Current elision proposal

[Rich Felker]

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