This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: TSX lock elision for glibc v12
- From: Rich Felker <dalias at aerifal dot cx>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org, Carlos O'Donell <carlos at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>
- Date: Thu, 20 Jun 2013 21:29:20 -0400
- Subject: Re: TSX lock elision for glibc v12
- References: <1371592286-22073-1-git-send-email-andi at firstfloor dot org> <1371753271 dot 964 dot 2220 dot camel at triegel dot csb> <20130621012328 dot GA29800 at brightrain dot 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