关于uC/OS-II中优先级翻转问题

引 言：

1 uC/OS-II的运行机制

　　在嵌入式系统的应用中，实时性是一个重要的指标，而优先级翻转是影响系统实时性的重要问题。本文着重分析优先级翻转问题的产生和影响，以及在uC/OS-II中的解决方案。

　　uC/OS-II采用基于固定优先级的占先式调度方式，是一个实时、多任务的操作系统。系统中的每个任务具有一个任务控制快OS_TCB，任务控制块记录任务执行的环境，包括任务的优先级，任务的堆栈指针，任务的相关事件控制块指针等。内核将系统中处于就绪态的任务在就绪表(ready list)进行标注，通过就绪表中的两个变量OSRdyGrp和OSRdyTbl[]可快速查找系统中就绪的任务。在uC/OS-II中每个任务有唯一的优先级，因此任务的优先级也是任务的唯一编号(ID)，可以作为任务的唯一标识。内核可用控制块优先级表OSTCBPrioTbl[]由任务的优先级查到任务控制块的地址。uC/OS-II主要就是利用任务控制快OS_TCB、就绪表(ready list)和控制块优先级表OSTCBPrioTbl[]来进行任务调度的。任务调度程序OSSched()首先由就绪表(ready list)中找到当前系统中处于就绪态的优先级最高的任务，然后根据其优先级由控制块优先级表OSTCBPrioTbl[]取得相应任务控制块的地址，由OS_TASK_SW()程序进行运行环境的切换。将当前运行环境切换成该任务的运行环境，则该任务由就绪态转为运行态。当这个任务运行完毕或因其它原因挂起时，任务调度程序OSSched()再次到就绪表(ready list)中寻找当前系统中处于就绪态中优先级最高的任务，转而执行该任务，如此完成任务调度。若在任务运行时发生中断，则转向执行中断程序，执行完毕后不是简单的返回中断调用处，而是由OSIntExit()程序进行任务调度，执行当前系统中优先级最高的就绪态任务。当系统中所有任务都执行完毕时，任务调度程序OSSched()就不断执行优先级最低的空闲任务OSTaskIdle()，等待用户程序的运行。

2 uC/OS-II中的优先级翻转问题

　　在uC/OS-II中，多个任务按照优先级高低由内核调度执行，而且任务调度所花的时间是常数，与应用程序中建立的任务数无关。对于占先式内核，任务的响应时间是确定的，而且是最优化的，占先式内核保证最高优先级的任务最先执行。

　　任务的响应时间=寻找最高优先级任务的时间+任务切换时间
　　
　　在uC/OS-II中寻找进入就绪态的最高优先级任务是通过查就绪表实现的，这减少了所需时间。
y=OSUnMapTbl[OSRdyGrp];
x= OSUnMapTbl [OSRdyTbl[y]];
prio=(y<<3)+x;

　　任务切换是通过调用汇编函数OS_TASK_SW()来实现的，主要完成两个任务运行环境的保存和恢复。因此用户可以通过安排任务的优先级，保证系统的实时性。当涉及到共享资源的互斥访问时，多任务实时操作系统常常会出现优先级翻转问题(priority inversion)，不能保证高优先级任务的响应时间，影响系统的实时性，uC/OS-II中也存在同样问题。所谓优先级翻转问题(priority inversion)即当一个高优先级任务通过信号量机制访问共享资源时，该信号量已被一低优先级任务占有，而这个低优先级任务在访问共享资源时可能又被其它一些中等优先级的任务抢先，因此造成高优先级任务被许多具有较低优先级的任务阻塞，实时性难以得到保证。例如：有优先级为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)两种办法。

　　优先级天花板是当任务申请某资源时，把该任务的优先级提升到可访问这个资源的所有任务中的最高优先级，这个优先级称为该资源的优先级天花板。这种方法简单易行，不必进行复杂的判断，不管任务是否阻塞了高优先级任务的运行，只要任务访问共享资源都会提升任务的优先级。在uC/OS-II中，可以通过OSTaskChangePrio()改变任务的优先级，但是改变任务的优先级是很花时间的。如果不发生优先级翻转而提升了任务的优先级，释放资源后又改回原优先级，则无形中浪费了许多CPU时间，也影响了系统的实时性。

　　优先级继承是当任务A申请共享资源S时，如果S正在被任务C使用，通过比较任务C与自身的优先级，如发现任务C的优先级小于自身的优先级，则将任务C的优先级提升到自身的优先级，任务C释放资源S后，再恢复任务C的原优先级。这种方法只在占有资源的低优先级任务阻塞了高优先级任务时才动态的改变任务的优先级，如果过程较复杂，则需要进行判断。uC/OS-II不支持优先级继承，而且其以任务的优先级作为任务标识，每个优先级只能有一个任务，因此，不适宜在应用程序中使用优先级继承。

3 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时间，有利于系统实时性的提高。

　　总之，优先级翻转问题是多任务实时操作系统普遍存在的问题，这个问题也存在于uC/OS-II中。通过在应用程序中进行简单的判断，在可能出现优先级翻转的情况下动态的改变任务的优先级，可以有效地避免任务的优先级翻转，保证高优先级任务的执行，提高了系统的实时性。

------------

关于μC/OS-II系列软件版权的说明

Micrium 公司产品包括μC/OS-II，μC/GUI，uC/FS，μC/TCP-IP，μC/USB等。Micrium 公司提供嵌入式系统应用方面的产品，并对其软件拥有知识产权。Micrium花费了大量的时间和财力为嵌入式领域提供高质量的软件产品。所有上述产品都以源代码的形式提供给客户，具有极大的适用性。产品不是免费软件，也不是开放源码的软件，因此，不能免费使用，需要清楚的阐明μC/OS-II和系列的软件不是开放源码的免费软件，这是和Linux完全不一样的。

开发和研究者可以通过购买Micrium公司的Jean先生的μC/OS-II的书籍，而得到μC/OS-II源代码,但是仅可以作为个人和学校学习使用，所有和μC/OS-II直接和间接相关的商业目的行为，必须购买使用μC/OS-II及系列产品的商业授权，包括芯片/单板/系统厂家的任何参考设计，教学设备和最终的产品，如果没有得到Micrium公司Jean先生签字的合法授权都是不合法的使用, 这在μC/OS-II的书籍Micrium公司(www.micrium.com)和中国代理商-北京麦克泰软件公司网站（www.bmrtech.com）上面中有明确规定。

Micrium公司其它软件如μC/GUI，μC/FS，μC/TCP-IP，μC/USB 等的销售模式与μC/OS-II不同，如果没有购买使用授权，完全不可以拥有该源代码，也不能将源代码用于产品的设计，培训，教学和生产。

μC/OS-II, μC/GUI，μC/FS，μC/TCP-IP，μC/USB 等授权方式有：单个产品、产品线（系列）、按照CPU 划分的产品三种形式，μC/OS-KA，μC/OS-VIEW 等工具是按照使用人的数目收取费用的，相对起传统的RTOS 动辄2-3万美圆的开发费用和每块单板的使用费（根据数量从数百到几个美圆），μC/OS-II及系列产品是采用一次性的收费方式，应该只是大约相当于传统RTOS 的10-20% 的总体费用。

如果您正在将μC/OS-II系列软件用于您的产品，您需要购买并获得正式使用授权。

北京麦克泰软件技术有限公司