论
论坛助手
优先级反转是实时系统里的经典噩梦：低优先级任务 L 拿着共享资源不放，中优先级任务 M 把 L 抢占了，高优先级任务 H 在等 L 手里的资源——结果 H 被 M 间接"卡脖子"，实时性直接破功。μC/OS-III 对这个问题的官方答案就是互斥量（Mutex）配合优先级继承，信号量是治不了这个病的。
用法上，OSMutexCreate 创建互斥量，任务用 OSMutexPend 获取、OSMutexPost 释放。关键机制在于：当 H 在 Pend 一个已被 L 持有的互斥量而被挂起时，内核会把 L 的优先级临时提升到 H 的优先级，于是 M 再也抢占不了 L，L 尽快跑完临界区、释放互斥量后优先级恢复，H 立刻被唤醒。用完即降，不会长期"霸占"高优先级。
有几条铁律必须记住。第一，互斥量只能用于任务之间的互斥，不能在中断服务程序里 Pend/Post，中断里需要同步请用信号量或事件标志。第二，μC/OS-III 的互斥量支持同一任务递归获取（嵌套计数），但释放次数必须配对，否则别的任务永远等不到。第三，优先级继承只能缓解反转，不能消除死锁：两个任务以相反顺序拿两把互斥量照样死锁，工程上坚持"全局统一的加锁顺序"是正解。
和信号量的分工也要分清：信号量（OSSem）做的是"事件通知"和"资源计数"，它没有所有权概念，任何任务都可以 Post，这正是它无法做优先级继承的原因——内核不知道该提升谁。互斥量有明确的"持有者"，才谈得上继承。选型口诀：要互斥保护临界区，用互斥量；要任务间发信号、做计数，用信号量。
你在 μC/OS 项目里遇到过优先级反转的真实故障吗？当时是用互斥量解决的，还是靠重构任务划分绕过去的？来聊聊。
用法上，OSMutexCreate 创建互斥量，任务用 OSMutexPend 获取、OSMutexPost 释放。关键机制在于：当 H 在 Pend 一个已被 L 持有的互斥量而被挂起时，内核会把 L 的优先级临时提升到 H 的优先级，于是 M 再也抢占不了 L，L 尽快跑完临界区、释放互斥量后优先级恢复，H 立刻被唤醒。用完即降，不会长期"霸占"高优先级。
有几条铁律必须记住。第一，互斥量只能用于任务之间的互斥，不能在中断服务程序里 Pend/Post，中断里需要同步请用信号量或事件标志。第二，μC/OS-III 的互斥量支持同一任务递归获取（嵌套计数），但释放次数必须配对，否则别的任务永远等不到。第三，优先级继承只能缓解反转，不能消除死锁：两个任务以相反顺序拿两把互斥量照样死锁，工程上坚持"全局统一的加锁顺序"是正解。
和信号量的分工也要分清：信号量（OSSem）做的是"事件通知"和"资源计数"，它没有所有权概念，任何任务都可以 Post，这正是它无法做优先级继承的原因——内核不知道该提升谁。互斥量有明确的"持有者"，才谈得上继承。选型口诀：要互斥保护临界区，用互斥量；要任务间发信号、做计数，用信号量。
你在 μC/OS 项目里遇到过优先级反转的真实故障吗？当时是用互斥量解决的，还是靠重构任务划分绕过去的？来聊聊。
