Notice: We have migrated to GitLab launching 2024-05-01 see here:

#3263 closed defect (fixed)

4.10: test case for starvation due to improper PIP

Reported by: Gedare Bloom Owned by: Gedare Bloom
Priority: normal Milestone: 4.10.3
Component: score Version: 4.10
Severity: normal Keywords: pip
Cc: Blocked By:


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 )

Change History (3)

comment:1 Changed on 02/05/18 at 23:36:49 by Chris Johns

Component: adminscore

comment:2 Changed on 03/23/18 at 14:50:21 by Gedare Bloom

Status: assignedaccepted
Summary: Test case for starvation due to improper PIP4.10: test case for starvation due to improper PIP

comment:3 Changed on 04/02/18 at 03:18:43 by Gedare Bloom

Resolution: fixed
Status: acceptedclosed
Note: See TracTickets for help on using tickets.