id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,blockedby,blocking 3362,4.11: test case for starvation due to improper PIP,Gedare Bloom,Gedare Bloom,"The following explains a scenario in rtems-4.10 that is solved by the scheduler resource changes made in the 4.11 development cycle. I have implemented this scenario as a test case. Task A, B and C A highest priority 0 B priority 1 And C, lowest Priority 2 In our example Task B will get starved unnecessarily. Task C: Takes Mutex X … Take Mutex Y (nested semaphore owned by Task C) Task C gets suspended by higher priority Task A Task A tries to obtain Mutex Y (but it is held by Task C) PIP protocol: Task C priority is raised to match Task A Task C runs again: Task C releases Mutex Y ( This is the point where Task C priority should be returned to normal, so Task A can run again, but it is not per the RTEMS documentation. It will not be lowered to its original priority until it releases ALL mutexes... so that means Mutex X. If X is held for a long time, then Task C will retain its elevated priority for that same long duration and thus starving all tasks i.e. Tasb B whose priority is between Task A and Task C ) .. Task C releases Mutex X ( This is where Task C priority finally does get returned to normal, and Task A can run again ) ",defect,assigned,normal,4.11.5,score,4.11,normal,,,,,