This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 03/14] Add elision to pthread_mutex_{try,timed,un}lock
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot jf dot intel dot com>
- Date: Fri, 28 Jun 2013 17:21:38 -0400
- Subject: Re: [PATCH 03/14] Add elision to pthread_mutex_{try,timed,un}lock
- References: <1372398717-16530-1-git-send-email-andi at firstfloor dot org> <1372398717-16530-4-git-send-email-andi at firstfloor dot org> <51CD3588 dot 6020603 at redhat dot com> <20130628195926 dot GD6123 at two dot firstfloor dot org>
On 06/28/2013 03:59 PM, Andi Kleen wrote:
>>> - switch (__builtin_expect (PTHREAD_MUTEX_TYPE (mutex),
>>> + switch (__builtin_expect (PTHREAD_MUTEX_TYPE_ELISION (mutex),
>>> PTHREAD_MUTEX_TIMED_NP))
>>> {
>>> /* Recursive mutex. */
>>> + case PTHREAD_MUTEX_RECURSIVE_NP|PTHREAD_MUTEX_ELISION_NP:
>>
>> Why isn't this a unique type in pthreadP.h?
>>
>> e.g. PTHREAD_MUTEX_RECURSIVE_ELISION_NP?
>
> There is currently no recursive elided mutex.
> It would seem odd to add a type that doesn't exist.
>
> I just added the check here, so that if someone
> enables elision explicitely for recursive locks,
> it's a nop, and not an assert failure.
>
> In the future when recursive mutexes are elided I'll
> add that type too.
That makes sense. Please add a comment to that effect.
Cheers,
Carlos.