RTOS内核基础：任务调度机制、任务状态机与上下文切换原理
各位同学，大家好。今天我们进入RTOS内核最核心的部分——任务调度。说实话，这部分内容我每次讲都觉得特别重要。你想想看，一个实时操作系统，它的灵魂就是怎么把CPU时间合理地分配给各个任务。如果调度搞不好，那系统响应再快也是白搭。
我在车载项目里见过太多因为调度问题导致的故障了。有一次，一个同事写的代码，任务优先级设得乱七八糟，结果高优先级任务一直占着CPU，低优先级任务饿死了。嗯，这种问题在调试阶段特别难查，因为不是每次都能复现。所以，把调度机制吃透，是咱们做车载软件的基本功。
一、抢占式调度 vs 协作式调度
先说说两种最基本的调度方式。说白了，就是「谁说了算」的问题。
1. 抢占式调度（Preemptive Scheduling）
抢占式调度，就是操作系统说了算。每个任务都有优先级，高优先级的任务可以随时打断低优先级任务的执行。我个人的习惯是，在车载系统中，90%以上的场景都用抢占式调度。为什么？因为实时性要求高啊。
举个例子：
// 任务A：低优先级，负责显示
void Task_Display(void *param) {
while(1) {
update_screen(); // 正在更新屏幕
vTaskDelay(100); // 假设这里还没执行到
}
}
// 任务B：高优先级，负责刹车控制
void Task_Brake(void *param) {
while(1) {
if (brake_pressed()) {
apply_brake(); // 立即执行刹车
}
vTaskDelay(10);
}
}你看，如果Task_Display正在执行，突然刹车信号来了，Task_Brake会立刻抢走CPU。这就是抢占式调度的好处——紧急任务不等待。
关键点：抢占式调度中，任务切换可能发生在任何时刻。这意味着你的共享数据必须用互斥量或信号量保护起来。我曾经在一个项目中，因为忘了加锁，两个任务同时修改一个全局变量，结果数据错乱了，车子在测试时出现了诡异的抖动。排查了整整两天才找到原因。
2. 协作式调度（Cooperative Scheduling）
协作式调度，就是任务自己说了算。每个任务主动让出CPU，其他任务才能运行。说白了，就是「你干完了我再干」。
这种调度方式在什么场景下用？我建议在那些任务执行时间非常确定、且不需要紧急响应的场景下使用。比如一些后台日志记录任务。
// 协作式调度示例
void Task_Log(void *param) {
while(1) {
write_log_to_flash(); // 写日志
task_yield(); // 主动让出CPU
}
}
void Task_Sensor(void *param) {
while(1) {
read_sensor_data(); // 读传感器
task_yield(); // 主动让出CPU
}
}避坑指南：我曾经在一个项目中，错误地在协作式调度里放了一个长时间运行的任务。结果那个任务一直不调用task_yield()，其他任务全部饿死了。系统看起来像死机了一样。所以，使用协作式调度时，一定要确保每个任务都不会长时间霸占CPU。
二、任务状态机
每个RTOS任务，其实就是一个有限状态机。我习惯把任务状态理解为「任务当前在干什么」。常见的状态有四种：
| 状态 | 含义 | 典型场景 |
|---|---|---|
| 就绪（Ready） | 任务可以运行，但还没轮到 | 等待调度器分配CPU |
| 运行（Running） | 任务正在使用CPU | 正在执行代码 |
| 阻塞（Blocked） | 任务在等待某个事件 | 等待信号量、队列、延时 |
| 挂起（Suspended） | 任务被暂停，不参与调度 | 调试时手动暂停 |
你想想看，任务在运行过程中，状态是怎么变化的？
- 创建任务后，它进入就绪状态，等着被调度。
- 调度器选中它，它就变成运行状态。
- 如果它调用vTaskDelay()或者等待信号量，它就进入阻塞状态。
- 阻塞条件满足后，它又回到就绪状态。
- 如果调用vTaskSuspend()，它就进入挂起状态。
个人经验：我在调试车载系统时，经常用状态监控工具查看每个任务的状态。如果发现某个任务长时间处于「就绪」状态但就是没运行，那大概率是优先级设置有问题。如果某个任务一直「阻塞」，那可能是它等待的事件永远不会发生——这就是典型的死锁前兆。
三、上下文切换原理
上下文切换，说白了就是「换人干活」。CPU正在执行任务A，突然要切换到任务B，那任务A的现场（寄存器、栈指针、程序计数器等）必须保存下来，等下次轮到它时再恢复。
这个过程，我建议你把它拆成三步：
- 保存当前任务上下文：把CPU寄存器压入当前任务的栈中。
- 选择下一个任务：调度器从就绪队列中选一个优先级最高的任务。
- 恢复新任务上下文：从新任务的栈中弹出寄存器值，然后跳转到它上次停下的地方继续执行。
代码层面，上下文切换通常用汇编实现。为什么？因为要直接操作CPU寄存器。我给大家看一个简化版的例子：
; 上下文切换汇编代码（简化版，基于ARM Cortex-M）
PendSV_Handler:
; 保存当前任务上下文
MRS R0, PSP ; 获取当前任务栈指针
STMFD R0!, {R4-R11} ; 保存R4-R11到栈中
; 保存栈指针到TCB
LDR R1, =CurrentTCB
LDR R2, [R1]
STR R0, [R2]
; 选择下一个任务
BL SelectNextTask
; 恢复新任务上下文
LDR R1, =CurrentTCB
LDR R2, [R1]
LDR R0, [R2] ; 获取新任务栈指针
LDMFD R0!, {R4-R11} ; 恢复R4-R11
MSR PSP, R0 ; 设置栈指针
BX LR ; 返回注意：上下文切换是有开销的。每次切换，CPU都要花几十到几百个时钟周期来保存和恢复现场。如果任务切换太频繁，系统大部分时间都在做切换，而不是做实际工作。我见过一个项目，把时间片设得太小，结果CPU利用率只有60%，剩下40%全浪费在切换上了。嗯，这就是典型的「过度调度」。
四、实际调优建议
讲了这么多理论，咱们来点实际的。在车载RTOS中，我总结了几条调优经验：
- 优先级不要超过7级：优先级太多，调度器选择任务的时间会变长。我一般用3-5级就够了。
- 时间片设10ms左右：太短切换开销大，太长实时性差。10ms是个不错的折中。
- 避免优先级反转：低优先级任务持有高优先级任务需要的资源时，会导致高优先级任务被阻塞。用优先级继承协议可以解决。
- 监控任务栈使用率：栈溢出是嵌入式系统的常见问题。我习惯给每个任务多分配20%的栈空间作为安全余量。
一个小技巧：在调试阶段，可以打印每个任务的上下文切换次数。如果某个任务切换次数异常多，说明它可能被频繁打断，或者它的优先级设置不合理。我曾经用这个方法，发现一个显示任务的切换次数是其他任务的10倍，后来把它的优先级降低了一级，系统整体响应反而更好了。
好了，今天的内容就到这里。任务调度是RTOS的基石，理解透了，后面的内容就顺了。下一章我们讲中断管理，那可是实时系统的另一个关键点。大家回去可以想想：如果中断和任务同时触发，谁先执行？嗯，这个问题我们下次再聊。