Two possible solutions exist to deal with priority inversion. Using a MUTEX as an example:
a) Priority inheritance, wherein the priority of a task holding a MUTEX is temporarily raised to the priority of a task wishing to obtain a lock on the MUTEX, and
b) Priority ceiling, where the user at the MUTEX creation time specifies the maximum priority level at which a task holding a MUTEX should be raised to, and promises that no task requesting the MUTEX will have a priority higher than this preset limit.
Priority inheritance is the more flexible of the two, with the caveat that the task holding the MUTEX may have its priority raised multiple times depending on how many tasks are requesting a lock on the MUTEX. REXIS uses this scheme to address the issue of priority inversion.
REXIS also applies priority inheritance to the synchronous message passing API: once a task receives a message, the receiver task assumes the task priority of the sender task if it is higher than its own priority, since it is performing the task on the sender’s behalf. The task priority reverts once a reply message is sent back to the sender.