Re: Fw: [RFC] PI aware condvars

[Thomas Gleixner <tglx at linutronix dot de>]

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
>    supported.
>    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
autodetection :)
 
Thanks,

	tglx