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 Sun, 2013-01-13 at 16:20 -0500, Carlos O'Donell wrote:
> On 01/13/2013 03:43 PM, Andi Kleen wrote:
> > If the initializers are dropped the drawback however is that you
> > always need a function call, it'll be impossible to do with initializers.
> > It means that people would always need to write a constructor
> > for global locks
>
> I'm willing to concede on this point if you also work out
> a mechanism that includes the PSHARED value that we currently
> use to enable/disable process private futexes.
>
> At present PTHREAD_MUTEX_INITIALIZER can only be used to create
> process private mutexes.
>
> You also win by submitting something for PSHARED first, get that
> in and then simply add a new flag for elision (see below).
>
> > Ok one way would be to specify new initializers that
> > get additional parameters passed as macros , but I doubt that
> > will be any easier to read, than just having new initializer.
>
> That might be an interesting solution. I like where you're goin
> with this idea.
>
> e.g.
> PTHREAD_MUTEX_INIT_NP(lock, PTHREAD_PROCESS_PRIVATE \
> | PTHREAD_MUTEX_ELIDED);
>
> Seems readable?
Elsewhere in this thread Andi seemed to say that the HLE tunables are
just meant to be used for experiments, and not part of the standard ABI.
But how do we make sure programmers are aware of this? The identifiers
above don't tell me that ELIDED can go away whereas PRIVATE will not.
If these tunables are really just used for experiments, there's a lot
less need to change the API. Experiments can use out-of-band
mechanisms, could use separately shipped initializers, etc.
Thus, I think we first need to have a clear understanding of what the
purpose of these flags/hints and the target audience / uses cases are.
Anything that is meant to stay longer or will just need to stay (eg,
because it doesn't work well without tuning) has a much higher long-term
maintenance footprint, and thus requires more care when designing the
interface.
Torvald