[Bug nptl/11588] New: pthread condvars are not priority inheritance aware

["dvhltc at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>]

When using a PTHREAD_PRIO_INHERIT mutex with a condvar, the pthread_cond* calls 
can still cause an unbounded priority inversion via the internal condvar lock. 
The POSIX specification doesn't provide a mechanism to specify the protocol of 
the condvar. We would like to do this at runtime, but unfortunately it is legal 
to call pthread_cond_signal() or pthread_cond_broadcast() without first waiting 
on the lock, so the mutex type may not be known the first time the condvar is 
used. A new API, pthread_condattr_setprotocol_np() and 
pthread_condattr_getprotocol_np(), would allow the user to create a 
PTHREAD_PRIO_INHERIT condvar. This would use a PTHREAD_PRIO_INHERIT mutex for 
the internal condvar lock, eliminating the potential for hitting an unbounded 
priority inversion on that lock.

This topic was initially discussed here:
http://sources.redhat.com/ml/libc-alpha/2010-01/msg00011.html

And again here:
http://sources.redhat.com/ml/libc-alpha/2010-02/msg00089.html

Test cases and patches for evaluation will be attached.

-- 
           Summary: pthread condvars are not priority inheritance aware
           Product: glibc
           Version: 2.12
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
        AssignedTo: drepper at redhat dot com
        ReportedBy: dvhltc at us dot ibm dot com
                CC: dvhltc at us dot ibm dot com,glibc-bugs at sources dot
                    redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11588

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.