Re: TSX lock elision for glibc v12

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Jun 20, 2013 at 09:23:28PM -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.
> 
> 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.

To clarify, with my approach, the ONLY cases where applications would
get the no-elision penalty is when they explicitly create a
normal-type mutex or call pthread_mutexattr_settype without using the
new version of pthread.h. Using PTHREAD_MUTEX_INITIALIZER or
pthread_mutex_init without calling pthread_mutexattr_settype on the
attribute (or with a null attribute) would result in a default-type
mutex and thus would allow elision.

I think this approach would make even Andi happy. :-)

Rich