This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 09/14] Add a new pthread_mutexattr_setelision_np interface.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot jf dot intel dot com>, Roland McGrath <roland at hack dot frob dot com>
- Date: Tue, 02 Jul 2013 13:04:37 +0200
- Subject: Re: [PATCH 09/14] Add a new pthread_mutexattr_setelision_np interface.
- References: <1372452807-25216-1-git-send-email-andi at firstfloor dot org> <1372452807-25216-10-git-send-email-andi at firstfloor dot org> <51D09CA6 dot 7060700 at redhat dot com> <20130630215353 dot GL6123 at two dot firstfloor dot org>
On Sun, 2013-06-30 at 23:53 +0200, Andi Kleen wrote:
> > The fact is that elision is an
> > implementation detail of the underlying lock type. The library
> > should be deciding amongst the implementation details given
> > information it knows about the lock.
>
> The library already does that (that is what the "adaptive elision
> algorithm" is all about). But we don't have enough experience with
> the algorithm yet to be sure that it works well in all cases.
> Also for experimenting with the algorithms there needs to be some
> way to turn it on/off per lock. That is what the interface does.
There is a way to turn it off per lock: You just set the type explicitly
to PTHREAD_MUTEX_NORMAL via settype(). That requires the same
programmer effort as via setelision_np() or similar. There's no way to
always turn elision on for a particular lock no matter whether elision
is used by default -- but that might be less of a problem. Even if
elision is turned on for a particular lock, with the current code, this
lock will use the same adaptation algorithm as any other lock that uses
elision by default. So there's no full way to override the default
behavior.