RTOS调试中的优先级倒置

具有固定优先级调度程序的 RTOS 的核心思想是高优先级任务应该在低优先级任务之前调度。如有必要，RTOS 甚至可以抢占正在运行的任务，迫使它让 CPU 执行更高优先级的任务。然而，作为开发人员，您必须注意可能导致较高优先级任务必须等待较低优先级任务的编程缺陷——这种情况称为优先级倒置。

优先级反转可以与互斥体、消息队列或其他类型的同步对象一起发生。描述问题的最佳方式可能是通过一个示例来逐步说明。

在下面的时间线图中，使用 Tracealyzer 捕获，我们有一个低优先级任务（绿色）正在执行。它需要一个二进制信号量来保护某些临界区并继续在临界区内执行代码。当高优先级任务（红色）进入就绪状态时，RTOS 抢占绿色任务并让红色运行。红色任务尝试获取相同的二进制信号量，但由于低优先级绿色任务持有它而被阻止。

到目前为止，一切都很好——这是预期的行为。一般来说，绿色任务现在会运行并快速释放信号量，此时它再次被抢占，红色任务可以获取信号量并继续。然而，这一次发生了反转。出于某种原因，可能是定时等待已过期，中等优先级（橙色）任务已进入就绪状态并被允许在绿色任务之前执行。由于橙色任务不知道有争议的信号量，它很高兴地运行完成。只有这样，绿色任务才会最终运行，以便它可以释放信号量并将执行权交给红色的高优先级任务。

因此，高优先级任务被阻塞，必须等待不确定的时间，而中等优先级任务运行完成。这就是工作中的优先级倒置。

重要的是要意识到这里涉及的三项任务基本上是无能为力的。他们中没有一个人可以做任何事情来避免倒置，至少在没有 RTOS 的支持的情况下是这样。幸运的是，这种支持在许多 RTOS 中以具有优先级继承的互斥锁的形式提供。互斥量（互斥的缩写）是一种用于保护共享资源的信号量。优先级继承意味着如果一个高优先级的任务在试图获得一个低优先级任务当前持有的互斥锁时阻塞，那么持有该互斥锁的任务的优先级会暂时提高到被阻塞任务的优先级。在我们的场景中，当红色任务被阻塞时，绿色任务将被提升为红色优先级，从而有效地阻止了橙色任务的运行。

优先级继承并不能真正治愈优先级倒置，它只是在某些情况下将其影响最小化。硬实时应用程序仍应仔细设计，以便一开始就不会发生优先级反转。

通常，尽可能避免阻塞共享资源。例如，如果您的任务将数据写入消息队列（可能已满），您可以改为使用足够大但未满的队列，作为额外的预防措施，以非阻塞方式写入并检查任何失败写入的返回值。而不是使用分散在代码中的多个关键部分（共享互斥锁），您可以创建一个“服务器”任务，该任务对资源执行所有直接 *** 作，并使用消息队列从“客户端”任务中获取请求，在非-阻塞方式。服务器可以通过请求中指定的其他消息队列发送任何回复，这些消息队列由客户端任务拥有。

审核编辑：郭婷