This is the mail archive of the
mailing list for the glibc project.
Re: Fw: [RFC] PI aware condvars
- From: Thomas Gleixner <tglx at linutronix dot de>
- To: Dinakar Guniguntala <dino at in dot ibm dot com>
- Cc: libc-alpha at sources dot redhat dot com, Ulrich Drepper <drepper at redhat dot com>, Darren Hart <dvhltc at us dot ibm dot com>
- Date: Mon, 22 Feb 2010 19:45:40 +0100 (CET)
- Subject: Re: Fw: [RFC] PI aware condvars
- References: <20100222182541.GA4883@in.ibm.com>
On Mon, 22 Feb 2010, Dinakar Guniguntala wrote:
> Hi Ulrich,
> Did you get a chance to take a look at the PI aware condvar patch.
> More specifically, I would like your opinion on points 1 and 2
> listed below. Thanks,
Yes, it would be nice to have actual glibc support for this. There are
real world applications which suffer from the priority inversion
problem of condvars.
> 1. Add two new APIs to explicitly set the condvar to be PI aware,
> pthread_condattr_getprotocol_np and pthread_condattr_setprotocol_np.
> These two APIs are functionally equivalent to the
> pthread_mutexattr_g(s)etprotocol functions and accept the same set of
> arguments. (PTHREAD_PRIO_NONE, PTHREAD_PRIO_INHERIT and
> PTHREAD_PRIO_PROTECT). Though PTHREAD_PRIO_PROTECT is currently not
> The initial approach tried to avoid creating these two new APIs and
> instead checked to see if the mutex associated with the condvar
> was PI. If so it then used the PI kernel primitives for the cond lock.
> However the signalling thread (pthread_cond_broadcast/signal) can
> race with the waiter thread (pthread_cond_(timed)wait) and so it is
> not always possible to determine what kind of a mutex is associated
> with the condvar at signal time, which is what led to these 2 new APIs.
I think that approach is sane. I was never fond of the magic