嵌入式实时系统中由于多任务共享资源，通常会出现一些奇怪的现象。本文就什么是优先级反转及其产生原因进行分析，并提出2个行之有效的解决方案。接下来就和嵌入式培训班一起来看一下吧!

什么是优先级反转？

RTOS普遍具有2个特点：实时性和多任务。实时是指系统的响应时间必须在规定的时间内，超出这个时间限制将会使系统出现致命的错误;同时，实时性还要求对时间要求非常急迫的任务要先于对时间不是很紧急的任务执行。正是由于这2个原因，RTOS的进程调度普遍采用的是基于优先级的可抢占式PBP(Priority Based Preemptive)的调度策略。多任务是嵌入式系统的内在要求。

如今的嵌入式系统普遍要求具有多任务并发执行的能力，因此RTOS中也必须提供多任务并发执行的支持。由于多任务并发，必然会导致多个任务共享资源。如有2个任务task1和task2并发执行，都需要向打印机输出结果。由于只有1台打印机，所以在某个时间段内只能有1个任务，如task1占有打印机并向打印机输出，而这时另一个任务task2处于等待状态。当task1输出完毕后，task2由等待转为就绪，当RTOS再次调度它时，方可占有打印机向打印机输出。

试想如果不采取这种方式，不对打印机这种共享资源加以控制，而让task1和task2同时向打印机输出，这时候打印机打印的结果谁也看不懂，是一堆乱七八糟的东西。因此，大多数的RTOS采用了一种称作信号量(semaphore)的机制来实现对共享资源的管理。任何一个想使用临界资源(如打印机等共享资源)的进程在进入临界区(如task1或task2中访问临界资源的代码)之前必须拥有使用临界资源的信号量，否则不可以执行临界区代码。

假设系统中有3个任务，分别为task1、task2和task3。task1的优先权高于task2，而task2的优先权高于task3。恰在此时task1和task2 因某种原因被阻塞，这时候系统调度task3执行。task3执行一段时间后，task1被唤醒。由于采取的是PBP的调度策略，因此task1抢占task3的CPU, task1执行。task1执行一段时间后要进入临界区，但此时task3占有此临界资源的信号量。

因此task1被阻塞，处于等待状态，等待task3释放此信号量。经过这么一段时间后，task2此时此刻处于就绪状态。因此系统调度task2执行。如果task3在task2的执行期间一直没有能够被调度执行的话，那task1和task3将一直等到task2执行完后才能执行，task1更要等到task3释放它所把持的信号量才能执行;而这段时间完全有可能超出task1的Deadline，使得task1崩溃。

当系统看到有高优先级的任务崩溃时候，系统认为此时有重大事故发生，为了挽救系统，看门狗电路起作用，系统可能被自动复位。从上面的分析可以看到，导致系统崩溃的原因是由于优先级高的任务task1要获取被低优先级任务task2占有的临界资源而被task2阻塞，而具有中优先级的任务task2抢占task3的CPU,从而导致task2先于task1执行。这时候系统便出现了优先级反转的情况。

版权声明：转载文章来自公开网络，版权归作者本人所有，推送文章除非无法确认，我们都会注明作者和来源。如果出处有误或侵犯到原作者权益，请与我们联系删除或授权事宜。