This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 03/10] Add external interface changes: new lock typesfor pthread_mutex_t
On Fri, 2013-01-18 at 17:19 -0800, Andi Kleen wrote:
> > (c) Add specific pthread_mutexattr_*_np() functions to enable
> > or disable lock elision with the attribute used to create
> > the mutex. Add a new pthread's section in the manual to
> > describe these as "reqeust that lock elision be used if
> > available" etc. etc.
> >
> > I suggest creating a generic interface:
> > pthread_mutexattr_setparam_np(int parameter, int value);
> > pthread_mutexattr_getparam_np(int parameter, int value);
> >
> > Where paramter is one of:
> > PTHREAD_MUTEX_ELISION (your new bit)
> > PTHREAD_MUTEX_SHARED (the existing bit 31 for pshared)
>
> So I had it all coded up and tested, but for the PTHREAD_MUTEX_INIT_NP
> it's needed to support or'ing flags anyways:
>
> lock = PTHREAD_MUTEX_INIT_NP(PTHREAD_MUTEX_TIMED_NP|PTHREAD_MUTEX_ELISION_NP);
> lock = PTHREAD_MUTEX_INIT_NP(PTHREAD_MUTEX_TIMED_NP|PTHREAD_MUTEX_NO_ELISION_NP);
> lock = PTHREAD_MUTEX_INIT_NP(PTHREAD_MUTEX_TIMED_NP|PTHREAD_MUTEX_PSHARED_NP);
>
> but with that can as well or in pthread_mutexattr_settype() too:
>
> pthread_mutexattr_settype(&ma, PTHREAD_MUTEX_TIMED_NP|PTHREAD_MUTEX_ELISION_NP)
pthread_mutex_gettype then returns the elision bit as well, or not?
> and that's more consistent overall and the same everywhere. Also works for PSHARED.
>
> It also avoids adding new functions, which is a pain for binary compatibility.
> With that I'm dropping the pthread_mutexattr_setelision_np interfaces.
What about exposing tunables for locks in the way that Carlos suggested
for the general case? Then we avoid changes to the stable interface
except adding one function for any kind of future tunables?
Torvald