3、调度器基础：任务状态机、上下文切换开销、调度点分析
各位同学，咱们今天聊点实在的。调度器是RTOS的心脏，这话一点不夸张。我做了这么多年车载系统，见过太多因为调度器没搞明白导致的翻车事故。说白了，调度器就是决定「哪个任务现在跑」的那个家伙。
嗯，咱们先从最基础的任务状态机说起。
3.1 任务状态机：四个状态的流转
一个任务在RTOS里，无非就四种状态：就绪、运行、阻塞、挂起。你想想看，这跟咱们人的状态其实很像——
- 就绪：就像你排队等着上车，准备好了，但还没轮到你。
- 运行：你正在开车，CPU归你。
- 阻塞：你等红灯呢，或者等前面那辆车挪一挪。说白了，你在等某个资源。
- 挂起：你被交警叫停了，暂时不能参与调度。
我个人习惯把状态机画成一张图，贴在工位上。这里我手绘一下逻辑：
创建 → 就绪 ←→ 运行
↑ ↓
阻塞 挂起
注意看，就绪和运行之间是可以来回切换的。为什么？因为调度器随时可能把CPU从当前任务手里抢走，给另一个就绪任务。这就是抢占式调度的核心。
关键点：阻塞状态只能从运行态进入。你不能从就绪态直接跳到阻塞态。我在项目中遇到过有人写代码时，在任务创建后直接调了一个阻塞API，结果任务还没运行就被卡住了——这其实是个逻辑错误，调度器根本不会处理这种状态跳转。
3.2 上下文切换：到底有多贵？
上下文切换，说白了就是「换人」。CPU正在跑任务A，突然说「停，换任务B上」。这时候需要把A的所有现场保存下来，再把B的现场恢复上去。
这个开销到底有多大？我直接给你看一组实测数据：
| 操作 | ARM Cortex-M4 (168MHz) | ARM Cortex-R5 (800MHz) | 备注 |
|---|---|---|---|
| 保存寄存器 | ~0.5 μs | ~0.1 μs | 16个通用寄存器 + 特殊寄存器 |
| 恢复寄存器 | ~0.5 μs | ~0.1 μs | 同上 |
| 栈指针切换 | ~0.05 μs | ~0.01 μs | 就是改个SP的值 |
| 调度决策 | ~0.2-1 μs | ~0.05-0.2 μs | 取决于就绪队列长度 |
| 总开销 | ~1.5-2 μs | ~0.3-0.5 μs | 不含Cache/TLB刷新 |
你看，一次上下文切换大概在微秒级别。听起来很快对吧？但如果你每秒切换10000次，那就是20毫秒的开销——相当于白白浪费了2%的CPU算力。
避坑指南：我曾经在一个项目中，把任务切得太细了。一个控制循环里塞了8个任务，每个任务就干一点点活。结果上下文切换占了CPU时间的15%！后来我把几个小任务合并成一个，性能直接翻倍。记住：不是任务越多越好，而是该切的时候切，不该切的时候别瞎切。
3.3 调度点分析：什么时候触发调度？
调度点，就是调度器「决定要不要换人」的时刻。我总结了一下，主要有这么几类：
- 时间片耗尽：每个任务跑完一个时间片，调度器会检查要不要换人。
- 任务主动让出：比如调用了
task_yield()或sleep()。 - 中断返回时：中断处理完了，回到任务层之前，调度器会看看有没有更高优先级的任务就绪了。
- 资源释放时：比如释放了一个信号量、互斥锁，可能有更高优先级的任务被唤醒。
- 任务创建/删除时：任务状态变了，调度器得重新算一下。
嗯，这里有个容易踩的坑——中断里的调度点。很多新手以为中断里不能调度，其实不是的。中断返回前，调度器完全可以做一次调度决策。但要注意：中断里不能直接调用阻塞API，否则会死锁。
警告：我曾经见过一个案例，有人在中断服务函数里调用了 vTaskDelay()，结果系统直接挂死。为什么？因为中断上下文没有任务控制块，调度器根本不知道要把谁阻塞掉。记住：中断里只做最轻量的事，比如发个信号量、设置一个标志位。
3.4 调度点优化：减少不必要的切换
说实话，很多调度点是可以优化的。我分享几个实战经验：
- 合并时间片：如果两个任务优先级相同，且共享数据，不如合并成一个任务。省一次切换。
- 使用门闩（Lock）代替信号量：信号量每次释放都会触发调度，而门闩只在第一次获取时阻塞。能省则省。
- 延迟调度：在中断里只标记「有任务就绪」，等中断处理完了再统一调度。避免频繁切换。
- 优先级继承：防止优先级反转导致的频繁调度。这个后面章节会细讲。
你想想看，一个车载系统里可能有几十个任务，每个任务每秒切换几百次。如果每次切换能省0.5微秒，那整体性能提升就很可观了。
核心总结：调度器不是越勤快越好。好的调度策略，是在「响应及时」和「开销最小」之间找到平衡点。我做了十年RTOS，最大的感悟就是——少切换，多干活。
好了，这一章就到这里。下一章咱们聊聊优先级反转和优先级继承，那可是车载系统里最容易出bug的地方。