uCOS-II中任务的优先级翻转现象

  优先级翻转是RTOS内核所要面临和解决的问题，再继续源码阅读之前需要先了解一番。本文参照网上以及相关书籍，对优先级翻转扼要介绍。

1. 什么是优先级翻转

  什么是可剥夺型内核？若当前进程只是在进程执行结束，或者因某种原因而自动放弃CPU的使用权，导致其他的就绪任务获得CPU的使用权，这种方式实现的处理器使用权转移的内核属于不可剥夺型内核，反之，若当前进程并未执行完毕，它又不愿放弃CPU的使用权，而被强制终止执行，使得CPU的使用权归其他进程，这种内核属于可剥夺型内核。

  uCOS-II的内核属于可剥夺型内核。任务优先级反转则出现于可剥夺型的内核中：当任务以独占方式使用共享资源，会出现优先级低的任务先于高优先级的任务执行的现象。RTOS要求任务的响应时间必须是个常数：

任务的响应时间 = 寻找最高优先级任务的时间 + 任务的切换时间

  寻找目标任务的操作是通过查表的形式得到，这个时间是一定的，由于每个任务需要保存的数据也是一致的，所以这个时间也是一定的。那就可以得到结论：在uCOS-II中任务调度所花的时间是常数，它和应用程序以及任务个数无关。

  但是当涉及到共享资源的访问时，多任务实时操作系统往往会出现优先级翻转问题，即有可能出现低优先级的任务先于高优先级的任务执行，不能保证高优先级的任务的响应时间。

  例如，系统中有优先级为A、B和C的三个任务，其优先级为A > B > C，任务A、B处于挂起状态，等待某一事件发生，任务C正在运行，此时任务C开始使用某一共享资源S。在使用中，任务A等待的事件到来，即A转为就绪态，因它的优先级比B任务高，所以立即得到执行。这时任务A也要获取资源S，由于S正被任务C使用，因此任务A被挂起，任务C开始执行。若此时任务B等待的事件到来了，则任务B变为就绪态，因任务B的优先级比C高，任务B开始运行，直至运行完毕，任务C才得以执行，直达任务C释放共享资源S，任务A才得以执行。在这种情况下，任务的优先级发生了翻转：低优先级任务B先于A执行，不能保证的高优先级任务的响应时间。

2. RTOS解决优先级翻转的方法

  (1)设置天花板优先级
  实现：当任务申请到某时间资源时，将该任务的优先级提升到系统中可访问该资源的所有任务中的最高优先级(通过函数OSTaskChangePrio()改变任务优先级)，该优先级称为天花板优先级。当任务释放资源后需要改回原优先级。
  优点：简单易行，不需要复杂的判断操作。
  缺点：改变任务的优先级需要耗费时间，若不发生优先级翻转而去提升任务的优先级，任务释放资源后有需要改回原优先级，造成了CPU时间的浪费，影响了系统的实时性。

  (2)优先级继承
  实现：当任务A申请共享资源S时，若S正在被任务C使用，比较任务C与自身的优先级，若任务C的优先级<自身的优先级，则将任务C的优先级提升到自身的优先级，任务C释放资源S后再恢复任务C的原优先级。
  优点：在占有资源的低优先级任务阻塞了高优先级任务时才改变任务的优先级，尽量省去CPU的浪费。
  缺点：需要RTOS支持同优先级的任务不止一个。

3. uCOS-II对优先级翻转问题的解决

  uCOS-II综合了上述的两种方法：先判断占有共享资源的任务是否阻塞了高优先级任务，再决定是否提升，提升任务的优先级至天花板。即当任务A申请共享资源S时，首先判断是否有别的任务正占用该资源，若没有则A基础执行；若有任务C正在正在占有该资源，则判断任务C的优先级是否高于任务A自身，若是则A挂起，等待任务C释放该资源，若任务C的优先级低于任务A则提升任务C的优先级至天花板，当任务C释放资源后，再恢复到原优先级。

  鉴于效率考虑uCOS-II选择了优先级继承的方法中的判断操作，但为什么不是将占有资源的任务的优先级提升至要申请该资源的优先级呢？
  这是因为uCOS-II中的每个优先级只支持一个任务，所以直接将优先级提升至天花板。这样既解决了优先级翻转问题，而且较少占用CPU时间，提高于系统实时性。