[RTEMS Project] #3263: Test case for starvation due to improper PIP

[RTEMS trac]

#3263: Test case for starvation due to improper PIP
--------------------+----------------------
 Reporter:  Gedare  |      Owner:  Gedare
     Type:  defect  |     Status:  assigned
 Priority:  normal  |  Milestone:  5.1
Component:  admin   |    Version:  4.10
 Severity:  normal  |   Keywords:  pip
--------------------+----------------------
 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 )

--
Ticket URL: <http://devel.rtems.org/ticket/3263>
RTEMS Project <http://www.rtems.org/>
RTEMS Project