第三节：速率单调调度（RMS）—— 实时系统的“铁律”

各位工程师朋友，今天我们来聊聊RMS。说实话，我刚入行那会儿，觉得调度算法就是操作系统的事，跟我做运动控制有什么关系？直到有一次，我负责一个六轴机器人项目，三个轴同时跑周期性任务，结果时不时就丢步。查了三天，最后发现是任务优先级没设对。嗯，从那以后，RMS就成了我工具箱里的常客。

3.1 RMS的核心思想：周期越短，优先级越高

RMS的全称是Rate Monotonic Scheduling，翻译过来就是“速率单调调度”。这里的“速率”指的是任务执行的频率，频率越高，周期就越短。RMS的核心原则就一句话：任务的周期越短，优先级就越高。

你想想看，一个每1ms就要执行一次的任务，跟一个每100ms才执行一次的任务，哪个更紧急？显然是前者。如果让长周期的任务抢了CPU，短周期的任务就可能错过截止时间。我在一个高速贴片机项目中就吃过这个亏——视觉检测任务周期是2ms，但被一个10ms周期的通信任务打断了，结果相机采集的数据没来得及处理，贴片位置全偏了。

3.2 优先级分配：一个简单的例子

假设我们有三个周期性任务：

任务	周期 (T)	执行时间 (C)	RMS优先级
τ1（电机电流环）	1 ms	0.3 ms	最高
τ2（位置环）	5 ms	1.0 ms	中
τ3（通信任务）	20 ms	2.0 ms	最低

按照RMS规则，τ₁周期最短，优先级最高；τ₃周期最长，优先级最低。这个分配很直观，对吧？但实际项目中，我见过有人把通信任务优先级设得比控制环还高，理由是“通信丢了数据更麻烦”。结果呢？电机电流环被频繁打断，扭矩输出抖动，机器振动得跟筛子似的。

3.3 可调度性分析：Liu & Layland定理

光分配了优先级还不够，你得确认这些任务能不能在截止时间前全部完成。这就引出了经典的Liu & Layland定理。1973年，这两位大佬证明了：对于一组独立的周期性任务，如果使用RMS调度，那么它们可调度的充分条件是：

Σ (C_i / T_i) ≤ n · (2^1/n - 1)

其中：

• C_i：任务τ_i的最坏情况执行时间
• T_i：任务τ_i的周期
• n：任务数量

这个公式的右边，随着n增大，会趋近于ln2 ≈ 0.693。也就是说，当任务数量很多时，CPU利用率不能超过69.3%。

等等，你可能会问：“那剩下的30% CPU就浪费了？” 嗯，这里要注意——这个定理给的是充分条件，不是必要条件。也就是说，即使CPU利用率超过了这个值，系统仍然可能是可调度的。我见过不少系统跑到80%甚至90%的利用率，照样跑得稳稳的。但作为工程师，我建议你把这个69.3%当作一个安全红线。

3.4 更精确的测试：响应时间分析

如果你觉得Liu & Layland定理太保守，可以用更精确的响应时间分析。这个方法计算每个任务在最坏情况下的响应时间R_i，然后检查是否满足R_i ≤ T_i。

计算公式如下（迭代求解）：

R_i^(0) = C_i
R_i^(k+1) = C_i + Σ ( ceil(R_i^(k) / T_j) * C_j )   // 对所有优先级高于i的任务j

说白了，就是不断迭代，直到R_i收敛。如果最终R_i ≤ T_i，那就说明任务可调度。

我个人习惯用这个方法来验证关键任务。比如在伺服驱动器中，电流环的响应时间必须严格小于1ms，用响应时间分析可以精确算出它会不会被其他任务阻塞。

3.5 RMS的局限性

RMS不是万能的。我总结了几点实际项目中容易踩的坑：

• 任务间有共享资源：如果任务需要互斥访问共享内存或外设，优先级反转就可能发生。低优先级任务拿着锁，高优先级任务只能干等。这时候需要配合优先级继承协议。
• 任务不是严格周期性的：有些任务是偶发的（比如报警处理），RMS就不太适用了。
• 任务执行时间变化大：如果C_i的波动范围很大，用最坏情况去算，利用率会很低。

3.6 知识体系图

下面这张图总结了RMS的核心逻辑，我画出来方便你理解：

3.7 实战中的几点提醒

最后，分享几个我在项目中积累的小经验：

• 测量实际执行时间：别光看数据手册。用示波器或逻辑分析仪抓一下任务的执行时间，你会发现理论值和实际值往往有差距。我见过一个任务，手册上写0.5ms，实际跑起来因为缓存未命中，能飙到1.2ms。
• 留有余量：即使可调度性分析通过了，也建议留出20%以上的CPU余量。系统运行久了，任务可能会因为中断、缓存、DMA等因素变慢。
• 考虑最坏情况：做响应时间分析时，一定要用最坏情况执行时间（WCET）。平均执行时间好看，但关键时刻掉链子就麻烦了。

---

公众号:蓝海资料掘金营，微信deep3321