Re: TSX lock elision for glibc v12

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2013-06-20 at 21:23 -0400, Rich Felker wrote:
> On Thu, Jun 20, 2013 at 08:34:31PM +0200, Torvald Riegel wrote:
> > Carlos asked me to send a more detailed plan for how we could split up
> > Andi's work so that we can commit the parts that we can (hopefully) get
> > consensus on before the freeze.  This might have some rough edges, but
> > should show what I have in mind.  Comments?
> > 
> > 1) Give PTHREAD_MUTEX_DEFAULT a new enum value != 0 (and thus not equal
> > to PTHREAD_MUTEX_NORMAL's value)
> 
> I agree this would be a better choice than changing the value of
> PTHREAD_MUTEX_NORMAL. However, I have one additional idea: what about
> swapping the two values when they move from pthread_mutexattr_t to
> pthread_mutex_t? That way, existing mutexes initialized by
> PTHREAD_MUTEX_INITIALIZER would have default type (and thus could use
> elision) rather than having normal type. This is the approach we'll
> probably use in musl if we add elision at some point.

Right, and that's the direction we discussed in the 2.18 thread just a
while before you posted this.  Please have a look.

> On the other hand, glibc has non-default-type mutex initializer
> macros, so we might have to consider whether any of them are
> documented to have the "normal" behavior rather than the "default"
> behavior. I'm not clear on this.

Right, that's also discussed in the other thread.  Carlos cited
documentation that hints at them being rather NORMAL than DEFAULT, but
those docs don't say so explicitly for the critical case (block when you
try to relock a lock you already acquired).