Hi Michael, I've tried many times over the last several years to get proper priority inheritance support for pthread condition variables added to glibc. Unfortunately, I haven't convinced the powers that be to incorporate the proposed fixes. Since the failure scenario involves an opaque type and is rather non-intuitive, it was suggested (thanks Frank) that I attempt to at least document the behavior. The goal is to discourage the use of condition variables in real-time applications as they have the potential for catastrophic system failure which could lead to loss of life - at least until such time as support is incorporated into the C library. I understand PTHREAD_COND_TIMEDWAIT(3P) is not Linux specific. I wonder if you could recommend an appropriate document for the following blurb: While the Linux kernel, since 2.6.31, supports requeueing of priority-inheritance (PI) aware mutexes via the FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI futex operations, the glibc implementation does not yet take full advantage of this. Specifically, the condvar internal data lock remains a non-PI aware mutex, regardless of the type of the pthread_mutex associated with the condvar. This can lead to an unbounded priority inversion on the internal data lock even when associating a PI aware pthread_mutex with a condvar during a pthread_cond*_wait operation. For this reason, it is not recommended to rely on priority inheritance when using pthread condition variables. -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
