We have 3 tasks running at different priorities: A (120), B (110), C (100). A takes a mutex semaphore with the Inversion Safe flag. Task B does a semTake, which causes Task A's priority to be elevated to 110. Later, task C does a semTake. Task A's priority is now 100.
At this point, A releases the semaphore and C grabs it. We notice that A's priority did not go back down to its original priority of 120. Shouldn't A's priority be restored right away?
Ideally, when the inherited priority level is
lowered, it will be done in a step-wise fashion. As each
dependency that caused the priority level to be bumped up is removed,
the inherited priority level should drop down to the priority level of
the highest remaining dependency.
For Example:
task A (100 bumped up to 80) has two mutexes (X & Y) that tasks B (pri 90) and task C (pri 80) are respectively pending for. When task A gives up mutex Y to task C, we might expect that its priority will drop to 90. When it finally gives up mutex X to task B, we would expect its priority level to drop back to 100.
Priority inheritance does not work that way in VxWorks.
How it works depends on the version of VxWorks you are using.
pre-VxWorks 6.0
The priority level remains "bumped up" until the task that has the lock on the mutex semaphore gives up its last inversion safe mutex semaphore.
Using the example from above, when task A gives up mutex Y to task C, its priority remains at 80. After it gives up mutex X to task B, then its priority will drop back to 100 (skipping 90).
Let's throw curve ball #1 into the mix. What if task A had a lock on mutex Z while all this was going on, but no one was pending on Z? In that case, the priority level will remain at 80 until Z is given up--then it will drop back to 100.
Why do it this way?
It's simple, and for most cases, it is good
enough. However, it does mean that when "curve ball #1" comes into
play, the priority will remain higher for a longer period of time than
is necessary.
VxWorks 6.0+
The priority level now remains elevated until the task that has the lock on the mutex semaphore gives up its last inversion safe mutex that contributed to raising the priority level.
This improvement avoids the problem of "curve ball #1". It does have its own limitations. For example, if task B and/or task C time(s) out while waiting for task A to give up the semaphores, task A's priority level does not get recalculated until it gives up the semaphore.