4、任务调度机制：抢占式调度、时间片轮转调度、协作式调度

调度机制，说白了就是操作系统决定「下一个该谁跑」的规则。我做了十几年嵌入式开发，见过不少产品因为调度选型不当而翻车。有的系统跑着跑着就卡死了，有的任务优先级设了一堆却毫无效果。嗯，今天咱们就把这三种调度机制掰开揉碎讲清楚。

4.1 抢占式调度：谁急谁先上

抢占式调度，是实时操作系统里最常用的方式。它的核心逻辑很简单：高优先级的任务可以「抢」低优先级任务的CPU使用权。

举个例子。你正在写文档，突然领导说「马上开个紧急会议」。你得放下手头的事去开会。开完会再回来继续写。这就是抢占。

在RTOS里，每个任务都有优先级。当高优先级任务就绪时，系统会立刻保存当前任务的上下文，切换到高优先级任务执行。我遇到过的一个项目里，通信中断服务程序必须抢占普通计算任务，否则数据包就会丢失。那时候我深刻体会到——抢占不是选项，是刚需。

不过，抢占式调度也有坑。我曾经在一个多任务系统中，三个任务互相抢占，结果低优先级任务一直得不到CPU时间——这就是「饥饿」现象。你想想看，如果某个低优先级任务是心跳检测，那系统就危险了。

4.2 时间片轮转调度：人人有份

时间片轮转调度，说白了就是「轮流坐庄」。每个任务分到固定的时间片，时间到了就换下一个。不管任务优先级高低，大家都有机会跑。

我刚开始做UI系统时，特别喜欢用这种方式。因为界面刷新、按键扫描、数据更新这些任务，优先级差不多，谁也不该霸占CPU太久。时间片轮转正好解决了这个问题。

举个例子。三个任务A、B、C，每个时间片10ms。顺序就是A跑10ms→B跑10ms→C跑10ms→A跑10ms……如此循环。每个任务都能得到公平的CPU时间。

调度方式	适用场景	优点	缺点
时间片轮转	同优先级任务较多	公平、无饥饿	实时性差
抢占式	实时性要求高	响应快	可能产生饥饿
协作式	简单系统	实现简单	任务可能阻塞

时间片轮转有个关键参数——时间片长度。太短了，频繁切换浪费CPU；太长了，其他任务等得着急。我个人的习惯是：时间片设为系统心跳的1~3倍。比如系统心跳是1ms，时间片就设2~3ms。这样既不会太频繁切换，也不会让其他任务等太久。

4.3 协作式调度：自觉排队

协作式调度，也叫非抢占式调度。它的规则是：任务自己决定什么时候让出CPU。说白了就是「你不主动让，别人就等着」。

这种调度方式在早期的嵌入式系统里很常见。我记得刚入行时，用的一个8位单片机就是协作式调度。每个任务里都要手动调用一个yield()函数，告诉系统「我干完了，换人吧」。

协作式调度的好处是：没有抢占，所以不需要处理临界区保护。坏处也很明显：如果一个任务死循环或者执行时间过长，整个系统就卡死了。

// 协作式调度示例
void task_led(void) {
    while(1) {
        toggle_led();
        delay_ms(100);  // 模拟工作
        task_yield();   // 主动让出CPU
    }
}

void task_key(void) {
    while(1) {
        scan_key();
        task_yield();   // 主动让出CPU
    }
}

你想想看，如果task_led里忘了调用task_yield()，那task_key就永远没机会执行。我曾经在一个项目中，实习生写的任务里有个while循环忘了加yield，结果整个系统看起来就像死机了一样。排查了半天才发现问题。

4.4 三种调度机制的选择策略

实际项目中，这三种调度机制往往不是非此即彼。很多RTOS支持混合调度：高优先级任务用抢占式，同优先级任务用时间片轮转。

我个人的经验是：

• 硬实时任务（比如中断响应、数据采集）→ 用抢占式，优先级设高
• 软实时任务（比如UI刷新、日志记录）→ 用时间片轮转，同优先级
• 简单系统（比如单功能控制器）→ 用协作式，实现简单

举个例子。在保护装置里，故障检测任务必须是抢占式，优先级最高。因为一旦发生故障，必须立刻响应。而人机界面任务可以用时间片轮转，因为用户操作没那么紧急。至于自检任务，用协作式就够了，反正它不着急。

嗯，调度机制就讲到这里。下一章咱们聊聊任务同步与通信——那又是另一个有意思的话题了。