实时操作系统优先级的反转与继承

使用实时内核，优先级反转问题是实时系统中出现最多的问题。

（1）       任务1和任务2处于挂起状态，等待某一事件的发生，任务3正在运行

（2）       此时，任务3要使用某共享资源。使用共享资源之前，必须首先得到该资源的信号量

（3）       任 务3得到了该信号量，并开始使用该共享资源

（4）       由于任务1优先级高，它等待的事件到来之后，剥夺了任务3的CPU使用权

（5）                                                                           

（6）       任务1开始运行。运行过程中，任务1也要使用任务3正大使用的资源。由于该资源的信号量还被任务3占用着，任务1只能进入挂起状态，等待任务3释放该信号量

（7）                                                                               

（8）       任务3得以继续运行。由于任务2的优先级高于任务3，当任务2等待的事件发生后，任务2剥夺了任务3的CPU的使用权并开始运行

（9）                                                                       

（10）   任务2处理该处理的事件，直到处理完后，将CPU使用权还给任务3

（11）    

（12）   任务3继续运行，直到释放共享资源的信号量。此时，由于实时内核知道有个高优先级的任务在等待这个信号量，内核做任务切换，使任务1得以运行

（13）   到此，任务1得到该信号量，并开始处理共享资源

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

纠正的方法可以是，在任务3使用共享资源时，提升任务3的优先级，任务完成后再恢复。这样会花费很多的CPU时间，真正需要的是，为防止发生优先级反转，内核能自动变换任务的优先级，这叫做优先级继承。

（1）

（2） 同先前例子，任务3正在运行，但此时，任务3申请互斥信号量（mutex），以获得共享资源的使用权

（3）

（4）任务3得到并开始使用共享资源，后来CPU胡使用权被任务1剥夺

（5）

（6）任务1开始运行，任务1申请共享资源信号量mutes，此时，内核知道该共享资源信号量mutes被任务3占用了，而任务3的优先级比任务1低，于是内核将任务3的优先级升到任务1相同

（7） 内核将任务1列入等待共享资源信号量mutex的任选列表中，然后回到任务3继续远行，任务3继续使用该共享资源

（8）任务3完成后，释放共享资源信号量mutes，这时，内核恢复任务3本来的优先级，并查看等待共享资源信号量mutes的任务列表，看是否有任务在等这个mutex,内核看到任务1在等这个mutex，把信号量mutex交给任务1

（9） 任务1得以顺利运行

（10）

（11） 任务1完成后，任务优先级在任务1与任务3之间的任务，例如任务2，才能得到CPU胡使用权，并开始运行