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: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- 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: Fri, 21 Jun 2013 12:48:06 +0200
- 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, 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).