Pthread Condition Variables and Priority Inversion
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.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel
Quoted 8 lines · Darren Hart
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.
< snip >
That reminds me... someone at Plumbers (I'm pretty sure it was Thomas) told me that the glibc maintainers have become much more responsive, so maybe I should encourage you to try once again, when you find some spare time :-), submitting to glibc.
-Frank
Quoted 10 lines · Frank Rowand
Quoted 8 lines · Darren Hart
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.
Quoted 6 lines
< snip >
That reminds me... someone at Plumbers (I'm pretty sure it was Thomas) told me that the glibc maintainers have become much more responsive, so maybe I should encourage you to try once again, when you find some spare time :-), submitting to glibc.
I think Jan and I both intend to do this, but until such time as we can, I'd like the docs to reflect reality.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel
<snip>
Quoted 7 lines
Quoted 2 lines
That reminds me... someone at Plumbers (I'm pretty sure it was
Thomas)
Quoted 3 lines
told me that the glibc maintainers have become much more responsive, so maybe I should encourage you to try once again, when you find some spare time :-), submitting to glibc.
Quoted 7 lines
I think Jan and I both intend to do this, but until such time as we can, I'd like the docs to reflect reality.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
We've run up against this condvar limitation on the system (glibc 2.15 on Linux with RT patch) we've been developing.
How can we help nudge the glibc maintainers? Is there some issue/fix voting system?
Cheers,
Carol
NetAcquire Corporation
Quoted 12 lines · Carol Wong
<snip>
Quoted 10 lines
Quoted 2 lines
That reminds me... someone at Plumbers (I'm pretty sure it was
Thomas)
Quoted 3 lines
told me that the glibc maintainers have become much more responsive, so maybe I should encourage you to try once again, when you find some spare time :-), submitting to glibc.
I think Jan and I both intend to do this, but until such time as we can, I'd like the docs to reflect reality.
Quoted 8 lines
Quoted 4 lines
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux KernelWe've run up against this condvar limitation on the system (glibc 2.15 on Linux with RT patch) we've been developing.
How can we help nudge the glibc maintainers? Is there some issue/fix voting system?
Well, at least this one is not working properly yet:
http://sourceware.org/bugzilla/show_bug.cgi?id=11588
Does someone have personal contact to a key persons from the community and can raise the awareness level there?
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
Quoted 20 lines · Jan Kiszka
Quoted 19 lines · Carol Wong
<snip>
Quoted 7 lines
Quoted 2 lines
That reminds me... someone at Plumbers (I'm pretty sure it was
Thomas)
Quoted 3 lines
told me that the glibc maintainers have become much more responsive, so maybe I should encourage you to try once again, when you find some spare time :-), submitting to glibc.
Quoted 7 lines
I think Jan and I both intend to do this, but until such time as we can, I'd like the docs to reflect reality.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux KernelWe've run up against this condvar limitation on the system (glibc 2.15 on Linux with RT patch) we've been developing.
Quoted 8 lines
Quoted 1 line
How can we help nudge the glibc maintainers? Is there some issue/fix voting system?
Well, at least this one is not working properly yet:
http://sourceware.org/bugzilla/show_bug.cgi?id=11588
Does someone have personal contact to a key persons from the community and can raise the awareness level there?
This bug has all the context, so this is definitely the place to focus. As for nudging people along in the right direction, I've tried appealing to Mark Brown and the POSIX committee without success. I suppose we could go back and review whatever changes were to the glibc development processes and email the relevant individuals.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel