优先级反转问题以及解决方式.docVIP

优先级反转问题以及解决方式 优先级反转的问题是每一个实时操作系统所必须考虑到的问题，也是嵌入式软件面试所常提问的问题。下面会详细阐述优先级反转产生的根源，以及解决方式。 首先来谈谈优先级反转问题的出现的方式。下图是演示优先级反转出现的问题。 假设有3个任务task1 优先级最高，task2优先级其次，task3优先级最低。假设task1 ，task2 分别阻塞在内核对象上比如queue等，然后轮到task3去运行,首先task3 获得了一个semaphore锁，然后运行了一段时间后，中断唤醒了task1,出中断的时候马上跑task1, 因为task1 的优先级高，然后task1也尝试去获得semaphore锁，但是task3 已经得到了这个锁，所以task1 只能睡眠，轮到task3 继续跑，这个时候中断唤醒了task2,出中断的时候轮到task2去跑，因为task2的优先级比task1要高。task2 运行完了然后给task3 跑，task3 跑完了才轮到task1去跑。 以上的现象就是一个完整的优先级反转的问题出现的现象，整个逻辑貌似都是完全没有任何问题的，唯一的问题就是task2跑完了再去跑task1,也就是说task2插了一脚。 task2 的优先级比起task1 要低的，这样的话task1 要同时承受task2 和task3 跑完才能继续跑。承受task3 跑完是没有任何争议的，因为临界区的原因，task1只能等task3跑完，但是task1等待task2 跑完确是不应该的，因为这两个任务之间毫无关系。 解决优先级反转的方式有两种，第一种是优先级置顶的方法，第二种是优先级继承的方法，详细请参考以下mutex章节。 Mutex工作原理以及应用 mutex 的出现是为了解决优先级反转的问题，由于优先级反转对实时性影响太大，所以mutex 的稳定性直接影响了实时性。纵观目前多种实时操作系统mutex 的设计原理是多多少少有一点问题的，很多rtos没有实现mutex优先级逐步还原的问题，导致了实时性以及其它的一些逻辑错误等等。raw os 的mutex 模块成功弥补了其它实时系统在这方面的不足。 Raw os 的mutex 同时支持优先级置顶和优先级继承的方式来解决优先级反转的问题。 优先级置顶方法需要给每一个mutex 静态指定一个优先级，第一个获得mutex 的任务会把优先级提高到静态指定的优先级。优先级置顶的方法需要把竞争这个mutex 的所有任务优先级都要搞清楚，通常适用于系统中运行的任务优先级不改变的情况。如果一个任务会获得多层嵌套的mutex锁，这个时候使用优先级继承的方法设计不好的话容易死锁，但是使用优先级置顶的方法能够避免此种情况出现。 下图是任务t3获得mutx1的情况，示例如下: 假设访问mutex1 的任务有t1, t2, t3, t1 的优先级为20， t2 的优先级为25， t3 优先级为 30，数字越小表明优先级越高。这个时候mutex1 指定的优先级置顶的优先级是19， 即比t1, t2 的优先级要高。假设任务t3的首先获得mutex1,这个时候任务t3的优先级会提升为19，所以t3会运行完之后释放锁轮到t1运行 综上所述，优先级置顶的话需要事先静态分析清楚，的确是比较麻烦的，好处是系统可以一目了然，不存在暗箱，做到系统每一个点都是很清楚。 再来谈谈优先级继承的方法, 所谓优先级继承的含义是，当优先级反转发生的时候，低优先级任务的优先级被自动提升为高优先任务的优先级, 示例如下： 假设任务t3 的优先级为30, t2优先级为25，t1优先级为20。因为数字越小优先级越高，所以t1优先级大于t2,t2优先级大于t3。假设t1和t2处于休眠状态， t3 会运行首先获得了锁， 然后在一个时间点高优先级任务t1被唤醒 ，抢占了t3, 然后t1 也尝试去获得锁，因为t3 已经获得了锁，所以t1只能睡眠，就在此时，任务t3的优先级被任务t1 拉升为20。任务t3会接着继续运行，如果此时t2被唤醒，因为优先级低于t3,所以不会抢占t3,所以t3会继续运行直到释放锁，然后t3的优先级会被还原到最初值，接着轮到最高优先级任务t1运行。整个过程的关键是中间优先级的任务t2不会打断t3,也就避免了优先级反转的问题。 优先级反转的问题掌握着实时系统的命脉，这个问题上处理的不当得话，用户的系统实时性是得不到任何保障的，纵观目前的RTOS 在mutex 这个问题上很多都是处理的不当的，具体以下分析代码会细谈这个问题。 Mutex api 应用 1 RAW_U16 raw_mutex_create(RAW_MUTEX *mutex_p