Zephyr 3.7的优先级继承：等待者为何会影响持锁线程

观察嵌入式软件的调度记录时，一个原本优先级较低的线程，可能在持有互斥锁期间暂时按更高优先级运行。若只拿最初配置的优先级作对照，容易误以为记录错乱。Zephyr 3.7.0互斥锁文档中的优先级继承，解释了这种变化的一项明确条件。[1]

互斥锁先确定资源的所有者。文档说明，线程需要取得互斥访问权才能使用相应共享资源；已经被其他线程锁定时，请求者可以等待。持锁线程是释放该锁的一方。也就是说，高优先级线程正在等锁，并不代表它已经取得资源，等待与持有是两个不同状态。

当更高优先级的线程开始等待某个互斥锁，内核可以暂时提高持锁线程的优先级，使它按等待者的优先级推进工作并释放锁。这里提高的是持有者，目的在于让等待所依赖的释放过程更快得到执行机会；它不是让等待者越过互斥关系直接使用仍被占用的资源。

这种优先级变化具有生命周期。文档描述，取得锁时会保存拥有者原来的优先级；释放锁后会恢复对应值，也讨论了高优先级等待者超时的情形。因此，在记录里看到某个较高优先级值，不能把它直接填入线程的永久基础配置，也不能仅凭一行调度结果推断整个固件的优先级设计已经改变。

原文还保留了两类限制。CONFIG_PRIORITY_CEILING会约束继承能够提高到的程度；涉及多个互斥锁时，释放顺序与此前提权关系可能产生不理想行为。文档说明单个已锁互斥锁的情形运作较好，不能把这一描述扩展为任意多锁组合都能获得相同效果。本文只识读限制，不给出项目的加锁顺序或调度参数修改方案。

准备解释一份等待记录时，可以先把锁的身份、持有者、等待者及各自状态对应起来，再区分基础优先级与临时优先级。这样讨论的是可核对的对象关系，而不是把“高优先级应先执行”当成不带条件的口号。本文没有运行固件、测量最坏响应时间或验证设备安全；优先级继承的文档机制，不能单独成为实时期限一定满足的证明。