4、任务调度基础：任务的概念与调度器工作原理
各位同学，今天我们聊聊任务调度。这是RTOS的核心，也是很多车载ECU工程师容易踩坑的地方。
我记得刚入行那会儿，总觉得任务调度不就是“谁先来谁先走”嘛。直到有一次，一个刹车控制模块在高速测试时出现了毫秒级的抖动，差点酿成大祸。从那以后，我才真正理解了——调度这件事，远比你想象的要复杂。
4.1 任务的概念：三种任务类型
在实时系统中，任务不是随便定义的。我们通常把任务分成三类：周期任务、偶发任务、非周期任务。说白了，就是看这个任务“什么时候来、多久来一次”。
4.1.1 周期任务
周期任务是最常见的。它每隔固定的时间间隔被激活一次。比如，一个发动机控制任务每10ms执行一次，这就是典型的周期任务。
关键特征：
- 激活间隔固定，记为T（周期）
- 执行时间相对稳定，记为C（最坏情况执行时间）
- 必须在截止时间D前完成，通常D = T
我在项目中遇到过一个问题：一个周期任务明明C只有2ms，T是10ms，按理说CPU利用率才20%，但系统就是会丢帧。后来发现，是中断服务程序抢占了太多时间。嗯，这里要注意——周期任务的“周期”是激活周期，不是执行周期。你算利用率的时候，得把中断也算进去。
4.1.2 偶发任务
偶发任务，说白了就是“不一定什么时候来，但来了就得处理”。它和周期任务最大的区别是：两次激活之间的最小时间间隔是已知的，但具体什么时候来，不确定。
举个例子：CAN总线上的错误帧处理。正常情况下可能几小时都不来一次，但一旦来了，必须在规定时间内响应。这种任务，你没法用周期任务的模型去分析。
我的经验：处理偶发任务时，我建议给它分配一个“预留带宽”。我曾经在一个项目中，把所有偶发任务都当周期任务处理，结果系统在极端工况下直接崩溃。后来我学乖了——给偶发任务留出30%的余量，再也没出过问题。
4.1.3 非周期任务
非周期任务，就是“完全随机”的任务。它没有最小间隔约束，可能连续来，也可能很久不来。比如，用户按下某个按钮触发的任务。
你想想看，这种任务最难处理。因为你没法预测它什么时候来，也没法保证它不会把系统压垮。在车载ECU中，我一般会把非周期任务放到后台，或者用优先级最低的方式处理。
| 任务类型 | 激活模式 | 典型例子 | 调度策略 |
|---|---|---|---|
| 周期任务 | 固定间隔 | 发动机控制（10ms） | RM、EDF |
| 偶发任务 | 最小间隔已知 | CAN错误处理 | 预留带宽 |
| 非周期任务 | 完全随机 | 用户按键 | 后台/最低优先级 |
4.2 调度器的工作原理
调度器，说白了就是RTOS的“大脑”。它决定下一个该运行哪个任务。我见过很多工程师把调度器想得太复杂，其实核心就三个问题：
- 什么时候切换？——调度点
- 切换到谁？——调度策略
- 怎么切换？——上下文切换
4.2.1 调度点
调度器不是随时都在工作的。它只在特定的“调度点”才做决策。常见的调度点有：
- 任务主动让出CPU（比如调用delay、wait）
- 任务被中断打断（中断返回时检查是否需要调度）
- 任务执行完毕（自动回到就绪队列）
- 定时器触发（比如时间片轮转）
我个人习惯把调度点画在时序图上。你画一次就明白了——调度点越密集，系统响应越快，但上下文切换开销也越大。这是个trade-off。
4.2.2 调度策略
最常见的调度策略是优先级抢占式调度。每个任务有一个优先级，就绪队列中优先级最高的任务先运行。如果高优先级任务就绪了，它会立即抢占当前运行的低优先级任务。
核心原则：优先级抢占式调度 + 同优先级时间片轮转
为什么会这样设计？你想想看，如果高优先级任务不能抢占，那它可能被低优先级任务阻塞，实时性就没了。但同优先级的任务之间，如果一直让一个任务跑，其他任务就饿死了。所以时间片轮转是必要的。
我曾经在一个项目中，把三个同优先级的任务都设成了“无限循环”，结果只有一个任务在跑，其他两个永远没机会。嗯，这就是典型的“优先级反转”的变种——虽然不完全是反转，但效果一样糟糕。
4.2.3 上下文切换
上下文切换，就是保存当前任务的状态，恢复下一个任务的状态。说白了，就是“换人”。
切换的内容包括：
- CPU寄存器（通用寄存器、程序计数器、栈指针）
- 浮点寄存器（如果有FPU）
- 任务控制块（TCB）中的状态信息
- MMU/MPU配置（如果有）
注意：上下文切换是有开销的！我见过一个项目，任务切换频率太高，结果CPU有30%的时间都在做切换，真正干活的时间只有70%。这就像你一天到晚在换工具，就是不干活。
4.3 上下文切换开销
上下文切换开销，说白了就是“换人”的时间成本。这个开销不是固定的，它取决于：
- CPU架构（ARM Cortex-M vs RISC-V，差别很大）
- 寄存器数量（通用寄存器越多，保存/恢复越慢）
- 是否使用FPU（浮点寄存器保存开销大）
- 调度器实现方式（纯软件 vs 硬件支持）
我给大家一个参考数据：在ARM Cortex-M4上，一次完整的上下文切换大约需要1-3微秒。听起来很短对吧？但如果你的系统有100个任务，每秒切换1000次，那光切换就占了3ms，也就是3%的CPU时间。
避坑指南：我曾经在一个项目中，把任务切分得太细。一个简单的控制逻辑，我分了5个任务。结果系统响应没变快，反而因为频繁切换变慢了。后来我合并了3个任务，性能反而提升了20%。所以，任务粒度要适中，别为了“看起来实时”而过度切分。
4.4 实际案例分析
我给大家讲一个真实的案例。某Tier1在做ADAS域控制器时，遇到了一个调度问题：
- 周期任务A：10ms周期，执行时间2ms
- 周期任务B：5ms周期，执行时间1ms
- 偶发任务C：最小间隔20ms，执行时间3ms
按照RM调度（速率单调调度），任务B优先级最高，任务A次之，任务C最低。但问题来了——任务C一旦触发，执行时间3ms，而任务B只有1ms。如果任务C执行时任务B就绪了，任务B会被阻塞最多3ms，而它的截止时间只有5ms。
你想想看，这会不会出问题？
答案是：会。如果任务C在任务B刚启动时触发，任务B可能被阻塞3ms，加上它自己的1ms执行时间，总共4ms，还在5ms内。但如果任务C在任务B启动后2ms触发，任务B被阻塞3ms，加上剩余执行时间，总共5ms，刚好卡在截止时间上。再差一点，就超时了。
解决方案是什么？我当时的做法是：把任务C的优先级提到任务A和任务B之间，但限制它的执行时间不超过2ms。如果超过2ms，就分多次执行。这样既保证了偶发任务的响应，又不会过度影响周期任务。
总结一下：任务调度不是简单的“谁优先级高谁先跑”。你得考虑任务类型、执行时间、截止时间、上下文切换开销。我做了十几年嵌入式，最大的体会就是——调度策略选对了，系统就成功了一半。
好了，这一章就到这里。下一章我们讲“实时性分析”，我会教大家怎么用数学方法判断一个任务集是否可调度。到时候见。