This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 03/10] Add external interface changes: new lock types for pthread_mutex_t


On Tue, Jan 22, 2013 at 02:44:20PM +0100, Torvald Riegel wrote:
> 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?

Currently it does yes.

> 
> > 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?

I don't like the idea very much to expose it to programs, but the 
environment variable interface I have already does it. That is it 
doesn't have any legacy support currently because there is no legacy,
but it could easily ignore obsolete fields.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]