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: Andi Kleen <andi at firstfloor dot org>
- Cc: Rich Felker <dalias at aerifal dot cx>, 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 15:23:31 +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> <20130621012920 dot GB29800 at brightrain dot aerifal dot cx> <20130621125906 dot GJ6123 at two dot firstfloor dot org>
On Fri, 2013-06-21 at 14:59 +0200, Andi Kleen wrote:
> > 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. :-)
>
> To make sure I understand your approach correctly:
>
> - Have a new ABI version of pthread_mutexattr_settype()
> - Define a new PTHREAD_MUTEX_NORMAL enum
> - The new ABI version of settype() would understand a
> new different value for PTHREAD_MUTEX_NORMAL and if that
> value is set, set either an additional disable elision
> or disable nested non trylock elision flag.
> It would enable elision for passing 0.
> - The old ABI version of settype would always set the
> no elision or no nested elision flags for the current 0 value
> (aka TIMED/NORMAL/DEFAULT)
> - Just using 0 in an initializer will not set any of the
> additional flags that disable elision.
>
> Is that correct?
That's not what I have in mind at least. See the 2.18 discussion
thread.