使用实时内核,优先级反转问题是实时系统中出现得最多的问题。图2.7解释优先级反转是如何出现的。如图，任务1优先级高于任务2，任务2优先级高于任务3。任务1和任务2处于挂起状态，等待某一事件的发生，任务3正在运行如[图2.7(1)]。此时，任务3要使用其共享资源。使用共享资源之前，首先必须得到该资源的信号量(Semaphore)(见2.
18.04信号量)。任务3得到了该信号量，并开始使用该共享资源[图2.7（2）]。由于任务1优先级高，它等待的事件到来之后剥夺了任务3的CPU使用权[图2.7(3)]，任务1开始运行[图2.7(4)]。运行过程中任务1也要使用那个任务3正在使用着的资源，由于该资源的信号量还被任务3占用着，任务1只能进入挂起状态，等待任务3释放该信号量[图2.7(5)]。任务3得以继续运行[图2.7(6)]。由于任务2的优先级高于任务3，当任务2等待的事件发生后，任务2剥夺了任务3的CPU的使用权[图2.7(7)]并开始运行。处理它该处理的事件[图2.7(8)]，直到处理完之后将CPU控制权还给任3[图2.7(9)]。任务3接着运行[图2.7(10)]，直到释放那个共享资源的信号量[图27(11)]。直到此时,由于实时内核知道有个高优先级的任务在等待这个信号量，内核做任务切换，使任务1得到该信号量并接着运行[图2.7(12)]。

    在这种情况下,任务1优先级实际上降到了任务3
的优先级水平。因为任务1要等,直等到任务3释放占有的那个共享资源。由于任务2剥夺任务3的CPU使用权,使任务1的状况更加恶化,任务2使任务1增加了额外的延迟时间。任务1和任务2的优先级发生了反转。

   
纠正的方法可以是,在任务3使用共享资源时,提升任务3的优先级。任务完成时予以恢复。任务3的优先级必须升至最高,高于允许使用该资源的任何任务。多任务内核应允许动态改变任务的优先级以避免发生优先级反转现象。然而改变任务的优先级是很花时间的。如果任务3并没有先被任务1剥夺CPU使用权，又被任务2抢走了CPU使用权,花很多时间在共享资源使用前提升任务3的优先级,然后又在资源使用后花时间恢复任务3的优先级,则无形中浪费了很多CPU时间。真正需要的是,为防止发生优先级反转,内核能自动变换任务的优先级,这叫做优先级继承(Priority
inheritance)但μC/OS-Ⅱ不支持优先级继承,一些商业内核有优先级继承功能。

图2.8解释如果内核支持优先级继承的话,在上述例子中会是怎样一个过程。任务3在运行[图2.8(1)],任务3申请信号量以获得共享资源使用权[图2.8(2)],任务3得到并开始使用共享资源[图2.8(3)]。后来CPU使用权被任务1剥夺[图2.8(4)],任务1开始运行[图2.8(5)],任务1申请共享资源信号量[图2.8(6)]。此时,内核知道该信号量被任务3占用了,而任务3的优先级比任务1低,内核于是将任务3的优先级升至与任务1一样,,然而回到任务3继续运行,使用该共享资源[图2.7(7)],直到任务3释放共享资源信号量[图2。8(8)]。这时,内核恢复任务3本来的优先级并把信号量交给任务1,任务1得以顺利运行。
[图2.8(9)],任务1完成以后[图2.8(10)]那些任务优先级在任务1与任务3之间的任务例如任务2才能得到CPU使用权,并开始运行
[图2.8(11)]。注意,任务2在从[图2.8(3)]到[图2.8(10)]的任何一刻都有可能进入就绪态,并不影响任务1、任务3的完成过程。在某种程度上,任务2和任务3之间也还是有不可避免的优先级反转。