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:23:28 -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>
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.
Rich