> Linux服务器 > Linux系统 >

优先级翻转

 uCos是一个典型的按照优先级调度的操作系统,优先级高的任务先运行,优先级低的任务后运行,然而在任务的调度过程中可能会出现优先级翻转的情况。在嵌入式系统的应用中,实时性是一个重要的指标,而优先级翻转是影响系统实时性的重要问题。
例如:有优先级为A、B和C三个任务,优先级A>B>C,任务A,B处于挂起状态,等待某一事件发生,任务C正在运行,此时任务C开始使用某一共享资源S。在使用中,任务A等待事件到来,任务A转为就绪态,因为它比任务C优先级高,所以立即执行。当任务A要使用共享资源S时,由于其正在被任务C使用,因此任务A被挂起,任务C开始运行。如果此时任务B等待事件到来,则任务B转为就绪态。由于任务B优先级比任务C高,因此任务B开始运行,直到其运行完毕,任务C才开始运行。直到任务C释放共享资源S后,任务A才得以执行。在这种情况下,优先级发生了翻转,任务B先于任务A运行。

优先级翻转的解决办法:
    从上面的分析中可以看出,优先级翻转其实是作为操作系统调度的一种异常情况出现的,操作系统的设计者其实是不想让这种情况出现的,所以优先级翻转是作为一个问题而存在的。解决优先级翻转问题有优先级天花板(priority ceiling)和优先级继承(priority inheritance)两种办法。

>>> 优先级天花板是当任务申请某资源时, 把该任务的优先级提升到可访问这个资源的所有任务中的最高优先级, 这个优先级称为该资源的优先级天花板。这种方法简单易行, 不必进行复杂的判断, 不管任务是否阻塞了高优先级任务的运行, 只要任务访问共享资源都会提升任务的优先级。

>>> 优先级继承是当任务A 申请共享资源S 时, 如果S正在被任务C 使用,通过比较任务C 与自身的优先级,如发现任务C 的优先级小于自身的优先级, 则将任务C的优先级提升到自身的优先级, 任务C 释放资源S 后,再恢复任务C 的原优先级。这种方法只在占有资源的低优先级任务阻塞了高优先级任务时才动态的改变任务的优先级,如果过程较复杂, 则需要进行判断。

uC/OS-II中优先级翻转问题的解决
    在uC/OS-II中,为解决优先级翻转影响任务实时性的问题,可以借鉴优先级继承的方法对优先级天花板方法进行改进。对uC/OS-II的使用,共享资源任务的优先级不是全部提升,而是先判断再决定是否提升。即当有任务A申请共享资源S时,首先判断是否有别的的任务正在占用资源S,若无,则任务A继续执行,若有,假设为任务B正在使用该资源,则判断任务B的优先级是否低于任务A,若高于任务A,则任务A挂起,等待任务B释放该资源,如果任务B的优先级低于任务A,则提升任务B的优先级到该资源的优先级天花板,当任务B释放资源后,再恢复到原优先级。在uC/OS-II中,每个共享资源都可看作一个事件,每个事件都有相应的事件控制块ECB。在ECB中包含一个等待本事件的等待任务列表,该列表包括OSEventTbl[]和OSEventGrp两个域,通过对等待任务列表的判断可以很容易的确定是否有多个任务在等待该资源,同时也可判断任务的优先级与当前任务优先级的高低,从而决定是否需要用OSTaskChangePio()来改变任务的优先级。这样,仅在优先级有可能发生翻转的情况下才改变任务的优先级,而且利用事件的等待任务列表进行判断,比用OSTaskChangePio()来改变任务的优先级速度快,并占用较少的CPU时间,有利于系统实时性的提高。


(责任编辑:IT)