This is the mail archive of the
mailing list for the glibc project.
Re: [PING][PATCH] Correct mutex type check for disable lock elision via pthread_mutexattr_settype call
- From: Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Wed, 30 Apr 2014 16:33:12 +0200
- Subject: Re: [PING][PATCH] Correct mutex type check for disable lock elision via pthread_mutexattr_settype call
- Authentication-results: sourceware.org; auth=none
- References: <lhdtdc$ek0$1 at ger dot gmane dot org> <li0os0$b95$1 at ger dot gmane dot org> <lig1d5$fhi$2 at ger dot gmane dot org> <lj8886$r3p$2 at ger dot gmane dot org>
On 04/23/2014 01:30 PM, Stefan Liebler wrote:
On 04/14/2014 09:06 AM, Stefan Liebler wrote:
ok to commit?
On 04/08/2014 02:08 PM, Stefan Liebler wrote:
On 04/01/2014 10:29 AM, Stefan Liebler wrote:
if glibc is build with --enable-lock-elision=yes,
all default mutexes are elided (only for supported architectures).
Someone can disable the elision for one specific mutex with
a call to pthread_mutexattr_settype.
Currently you can specify either PTHREAD_MUTEX_NORMAL or
PTHREAD_MUTEX_DEFAULT, because they are both defined to 0.
The function checks for type PTHREAD_MUTEX_DEFAULT
and then disables elision.
For correctness, the function should check against
According to POSIX, PTHREAD_MUTEX_NORMAL shall deadlock if a thread
tries to relock a mutex without first unlocking it.
In case of PTHREAD_MUTEX_DEFAULT, the behavior is undefined.
Thus the mutex can be elided with PTHREAD_MUTEX_DEFAULT, but not with
The same can be read in the lock elision implementation guidelines
2014-04-01 Stefan Liebler <email@example.com>
Disable lock elision for PTHREAD_MUTEX_NORMAL.