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: Andi Kleen <andi at firstfloor dot org>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Torvald Riegel <triegel at redhat dot com>, 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 14:59: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> <20130621012920 dot GB29800 at brightrain dot aerifal dot cx>
> 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?
I have to check it out a bit more first and do some grepping/testing,
but yes that approach could satisfy my compatibility requirements.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.