RTOS任务优先级反转

    优先级反转（Priority Inversion），是由于多任务共享资源，具有最高优先级的任务被低优先级任务祖册，反而使得具有中优先级的任务先于高优先级的任务执行，影响系统的实时性，甚至导致系统崩溃。

    具体说明如下：

    假设系统中有Task1、Task2、Task3三个任务，分别对应高、中、低三个优先级。

    某一时刻系统的状态如下：

T1：Task1和Task2正在等待某一事件的发生，处于挂起状态，Task3正在执行。

T2：Task1等待的事件发生，Task1剥夺Task3的CPU使用权开始执行，Task3被阻塞。

T3: Task1执行到某一时刻，需要申请Task3使用且还未释放的资源。则Task1挂起，Task3开始执行。

T4：Task3执行过程中，Task2进入就绪态，剥夺Task3的CPU使用权开始执行。

T5：Task2执行完，Task3开始执行。

T6：Task3执行完，释放资源，Task1开始执行。

    从上述过程中，可以看出Task1必须等待Task3执行完毕，释放资源之后才能得到该资源的使用权继续执行。这种情况下，Task1的优先级实际降到了Task3的优先级水平。在此过程中，处于中间优先级的Task2剥夺了Task3的CPU使用权，使Task1的状况恶化，即Task2使得Task1增加了额外的时间延迟，也就是Task1和Task2的优先级发生了反转。在更坏的情况下，如Task1和Task3之间有多个这样的“Task2”存在，这样的优先级反转问题可能会导致整个系统的崩溃。

    解决方案：

1）设置优先级上限，给临界区一个高优先级，进入临界区的进程都将获得这个高优先级，如果其他试图进入临界区的进程的优先级都低于这个高优先级，那么优先级反转就不会发生。

2）优先级继承，当一个高优先级进程等待一个低优先级进程持有的资源时，低优先级进程将暂时获得高优先级进程的优先级别，在释放共享资源后，低优先级进程回到原来的优先级别。嵌入式系统VxWorks就是采用这种策略。

####这里还有一个八卦，1997年的美国的火星探测器（使用的就是vxworks)就遇到一个优先级反转问题引起的故障。简单说下，火星探测器有一个信息总线，有一个高优先级的总线任务负责总线数据的存取，访问总线都需要通过一个互斥锁（共享资源出现了）；还有一个低优先级的，运行不是很频繁的气象搜集任务，它需要对总线写数据，也就同样需要访问互斥锁；最后还有一个中优先级的通信任务，它的运行时间比较长。平常这个系统运行毫无问题，但是有一天，在气象任务获得互斥锁往总线写数据的时候，一个中断发生导致通信任务被调度就绪，通信任务抢占了低优先级的气象任务，而无巧不成书的是，此时高优先级的总线任务正在等待气象任务写完数据归还互斥锁，但是由于通信任务抢占了CPU并且运行时间比较长，导致气象任务得不到CPU时间也无法释放互斥锁，本来是高优先级的总线任务也无法执行，总线任务无法及时执行的后果被探路者认为是一个严重错误，最后就是整个系统被重启。Vxworks允许优先级继承，然而遗憾的工程师们将这个选项关闭了。

3）第三种方法就是使用中断禁止，通过禁止中断来保护临界区，采用此种策略的系统只有两种优先级：可抢占优先级和中断禁止优先级。前者为一般进程运行时的优先级，后者为运行于临界区的优先级。火星探路者正是由于在临界区中运行的气象任务被中断发生的通信任务所抢占才导致故障，如果有临界区的禁止中断保护，此一问题也不会发生。