2、优先级反转的数学模型：用数学公式描述阻塞时间

好，咱们进入正题。

上一节我讲了优先级反转是什么，也举了个例子。但光有例子不够，做嵌入式系统的人，心里得有本账。你得能算出来：这个反转到底让我多等了多久？

说白了，我们需要一个数学模型。有了模型，你才能在设计阶段就预判风险，而不是等到产品跑起来才发现卡顿。

2.1 阻塞时间的定义

先给个定义。我个人习惯把阻塞时间叫做 T_block。

它指的是：一个高优先级任务，因为低优先级任务占用了共享资源，而被迫等待的时间。

注意，这个等待不是任务切换的开销，也不是中断延迟。它就是纯粹因为资源被占着，你拿不到，只能干等着。

嗯，这里要注意。这个公式看起来简单，但实际场景里，低优先级任务可能不止一个。而且中间还可能插进来一堆中等优先级的任务捣乱。

2.2 经典的三任务模型

我在项目中遇到过最典型的场景，就是三个任务打架：

• 任务H：高优先级，需要访问共享资源
• 任务M：中等优先级，不需要共享资源，但纯计算
• 任务L：低优先级，已经占着共享资源

你想想看，这时候会发生什么？

任务H想拿资源，发现被L占着，只能挂起。任务M一看，H挂起了，那CPU归我了。于是M开始跑，L反而被抢了CPU，没法释放资源。

这就是典型的优先级反转。H等着L，L等着M，M在那悠哉悠哉地算。

2.3 阻塞时间的数学推导

好，我们来算这笔账。

假设：

• 任务L持有资源的时间是 C_L
• 任务M的执行时间是 C_M
• 任务H的执行时间是 C_H

如果没有优先级反转，H的等待时间就是 C_L。但有了反转，情况就变了。

最坏情况下的阻塞时间：

T_block = C_L + C_M

为什么？因为H要等L释放资源，但L被M抢了CPU。所以H实际等了：L执行完剩下的时间 + M完整执行一遍的时间。

我当年第一次推导这个公式时，觉得太简单了。但后来发现，这个公式是很多系统崩溃的根源。因为C_M可能很大，大到让H的实时性完全丧失。

2.4 多任务场景下的扩展公式

如果不止一个中等优先级任务呢？

假设有 n 个中等优先级任务：M1, M2, ..., Mn。每个的执行时间分别是 C_M1, C_M2, ..., C_Mn。

那么最坏情况下的阻塞时间就是：

T_block = C_L + Σ(C_Mi)   (i从1到n)

这个 Σ 符号看着吓人，其实就是把所有中等优先级任务的执行时间加起来。

你想想看，如果 n=10，每个C_Mi=1ms，那光中等任务就占了10ms。再加上C_L，可能就奔着12ms去了。对于实时性要求1ms的系统来说，这简直是灾难。

2.5 优先级继承对阻塞时间的影响

那怎么解决？优先级继承就是一种常见手段。

简单说，就是当H被L阻塞时，L临时提升到H的优先级。这样M就抢不了L的CPU了。L赶紧跑完，释放资源，H就能继续。

加了优先级继承后，阻塞时间公式变成：

T_block_inherit = C_L

看到了吗？C_M被去掉了。因为L不会被M打断了。

但注意，这个C_L是L持有资源的那一段代码的执行时间，不是L整个任务的执行时间。很多新手会搞混。

场景	阻塞时间公式	说明
无反转（理想）	T_block = C_L	只有低优先级任务持有资源的时间
有反转（最坏）	T_block = C_L + Σ(C_Mi)	加上所有中等优先级任务的执行时间
优先级继承	T_block = C_L	恢复为理想情况，但C_L可能因继承而略有增加

2.6 实际应用中的注意事项

公式归公式，实际用的时候有几个坑：

• C_L 的测量：低优先级任务持有资源的时间不是固定的。它可能因为分支、循环而变化。我建议取最大值。
• 中断的影响：如果中断服务程序也访问共享资源，那阻塞时间还要加上中断处理时间。这个很多人会漏掉。
• 嵌套阻塞：如果一个任务持有多个资源，那阻塞时间会叠加。我曾经在一个项目里见过三层嵌套，算出来T_block直接超了任务周期。

2.7 小结

好，这一节的核心就一句话：阻塞时间 = 低优先级任务持有资源的时间 + 所有可能插队的中等优先级任务的时间。

这个公式虽然简单，但它是分析优先级反转的基石。你可以在设计阶段用它来估算最坏情况下的响应时间。如果算出来超了，那就得考虑优先级继承、优先级天花板，或者干脆重新设计任务结构。

下一节，我会讲具体的解决方案——优先级继承协议。到时候咱们再结合这个公式，看看实际代码里怎么落地。