Bug 438484

Description of problem:

pthread_cond_timedwait()/pthread_cond_wait()/pthread_cond_signal() use a mutex
(cond->__data.__lock) to protect internal data structures. This internal mutex
is not PIP making the condition variable implementation subject to priority
inversion.

Version-Release number of selected component (if applicable):


How reproducible:

Attached test reproduces the problem.

compiled with:
gcc -o ./pitest -D_GNU_SOURCE ./pitest.c -lpthread -lrt

run on a single processor:
taskset -c 0 ./pitest

It hangs because of the priority inversion...

- Thread 1 runs at priority 50
- Thread 1 grabs mutex mx
- Thread 1 starts Thread 2 at priority 70
- Thread 2 blocks waiting for mutex mx, Thread 1 is boosted to priority 70
- Thread 1 starts Thread 3 at priority 60. Thread 3 will loop taking all
the cpu if it can
- Thread 1 calls pthread_cond_wait() on condition variable cv with mutex
mx. Internally, it grabs the non-PI lock lx, then releases mutex mx. As
soon it drops mx, its priority drops to 50.
- Thread 2 resumes execution, releases mx, and calls pthread_signal on
cv. Internally it tries to grab the non-PI lock lx. It is owned by
Thread 1 so Thread 2 gives up the cpu.
- Thread 3 starts running and take all the CPU, thread 1 can't run:
priority inversion.


Steps to Reproduce:


1. 
2.
3.
  
Actual results:


Expected results:


Additional info: