第4章任务调度机制

第4章：任务调度机制——抢占式调度原理，时间片轮转，任务优先级设计与注意事项

各位同学，大家好。今天我们聊聊RTOS的核心——任务调度。说白了，调度器就是操作系统的“大脑”，它决定哪个任务在什么时候运行。我做了这么多年嵌入式，见过太多因为调度没搞明白而翻车的项目。嗯，这一章我们就把抢占式调度、时间片轮转和优先级设计这几个硬骨头啃下来。

4.1 抢占式调度原理

先问大家一个问题：一个低优先级的任务正在跑，突然来了一个高优先级的事件，怎么办？

抢占式调度的答案很简单——立刻打断低优先级任务，让高优先级任务先跑。这就是“抢占”二字的含义。

我记得刚入行时，有个同事用裸机写了个数据采集程序。主循环里轮询传感器，结果按键响应总是慢半拍。用户按了开关，要等好几秒才有反应。为什么？因为裸机没有抢占机制，任务只能排队等。换成RTOS的抢占式调度后，按键任务优先级设高，一按就响应，问题立马解决。

抢占式调度的核心机制是这样的：

每个任务都有一个优先级数值
调度器在系统Tick中断里检查：当前运行的任务是不是最高优先级的？
如果不是，立刻保存当前任务的上下文（寄存器、栈指针等）
然后恢复最高优先级任务的上下文，切换过去运行

看一个简单的抢占场景代码：

// 任务A：低优先级，负责LED闪烁
void TaskA(void *param) {
    while(1) {
        LED_Toggle();
        vTaskDelay(100);  // 主动让出CPU
    }
}

// 任务B：高优先级，负责紧急停止
void TaskB(void *param) {
    while(1) {
        if(紧急停止按钮按下) {
            Motor_Stop();
        }
        vTaskDelay(10);
    }
}

这里TaskB优先级高。一旦按钮按下，不管TaskA在干什么，调度器都会立刻切到TaskB。这就是抢占的魅力。

关键点：抢占式调度保证了高优先级任务的实时性。但代价是——低优先级任务可能被“饿死”。如果高优先级任务一直不释放CPU，低优先级任务永远没机会跑。

4.2 时间片轮转

好，那如果多个任务优先级相同呢？这时候就轮到时间片轮转出场了。

时间片轮转，说白了就是“轮流坐庄”。每个任务分到一个固定的时间片，比如10毫秒。时间到了，调度器强制切换给下一个同优先级的任务。

我在项目中遇到过这样一个情况：三个传感器采集任务，优先级都一样。如果不加时间片轮转，第一个任务会一直占着CPU，后面两个永远跑不了。加了时间片轮转后，每个任务轮流跑10ms，大家都有机会。

FreeRTOS中配置时间片轮转很简单：

// 在FreeRTOSConfig.h中
#define configUSE_TIME_SLICING      1   // 开启时间片轮转
#define configTICK_RATE_HZ          100 // 系统Tick频率，100Hz即10ms一个Tick

// 创建三个同优先级任务
xTaskCreate(Task1, "Task1", 256, NULL, 2, NULL);
xTaskCreate(Task2, "Task2", 256, NULL, 2, NULL);
xTaskCreate(Task3, "Task3", 256, NULL, 2, NULL);

三个任务优先级都是2。调度器会这样工作：

先跑Task1，跑完一个Tick（10ms）
切换到Task2，跑10ms
再切换到Task3，跑10ms
然后回到Task1，如此循环

你想想看，如果某个任务在时间片内主动调用了vTaskDelay()或者等待信号量，那它就会提前让出CPU，调度器会立刻切换到下一个就绪的同优先级任务。这叫“协作式让权”，和时间片轮转配合使用效果很好。

我的建议：时间片不要设得太短。太短会导致频繁切换，浪费CPU在上下文切换上。我一般设10-20ms，对大多数扫地机应用来说足够了。

4.3 任务优先级设计

优先级设计，这是RTOS应用中最容易翻车的地方。我曾经在一个项目中，把10个任务的优先级从0到9排得满满当当。结果呢？调试的时候自己都搞不清哪个任务该跑哪个优先级。后来我总结了一套方法，分享给大家。

4.3.1 优先级分配原则

我个人习惯把任务分成三类：

类别	优先级范围	典型任务
实时性要求极高	最高（如5-7）	电机急停、碰撞检测、IMU数据读取
实时性中等	中等（如3-4）	传感器轮询、通信处理、路径规划
后台任务	最低（如1-2）	日志记录、状态显示、电量统计

记住一个原则：优先级够用就行，不要滥用。能用3个优先级解决的问题，绝不用5个。

3.3.2 优先级反转问题

嗯，这里要重点讲一下优先级反转。这是RTOS里最经典的坑之一。

什么叫优先级反转？举个例子：

任务A（高优先级）和任务C（低优先级）共享一个互斥锁
任务B（中优先级）不共享这个锁
任务C先拿到了锁，然后被任务B抢占
任务A想拿锁，但锁在任务C手里，而任务C又被任务B抢占了
结果：高优先级的任务A，反而被中优先级的任务B阻塞了

我曾经在一个扫地机项目里遇到过这个问题。避障任务（高优先级）和电机控制任务（低优先级）共享一个I2C总线。结果避障任务经常超时，导致扫地机撞墙。查了两天才发现是优先级反转在作怪。

解决方案有两种：

优先级继承：当低优先级任务持有高优先级任务需要的锁时，临时把低优先级任务的优先级提升到和高优先级一样。这样中优先级任务就无法抢占它了。
优先级天花板：给每个互斥锁设定一个“天花板优先级”。任何任务拿到这个锁后，优先级自动提升到天花板级别。

FreeRTOS中可以用带优先级继承的互斥量：

// 创建互斥量（带优先级继承）
SemaphoreHandle_t xMutex = xSemaphoreCreateMutex();

// 任务中获取互斥量
if(xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
    // 访问共享资源
    I2C_ReadData();
    // 释放互斥量
    xSemaphoreGive(xMutex);
}

警告：千万不要用二值信号量来保护共享资源！二值信号量不支持优先级继承，遇到优先级反转时你哭都来不及。我见过有人这么干，结果系统跑着跑着就死机了。

4.4 避坑指南与实战建议

最后，我把自己这些年踩过的坑总结一下，希望对你有帮助。

我曾经...在一个项目里把所有任务优先级都设成一样，想着“反正时间片轮转会公平分配”。结果呢？一个任务里有个死循环忘了加延时，整个系统直接卡死。从那以后，我坚持给关键任务设高优先级，至少保证紧急情况能响应。

还有一次，我把一个任务的优先级设得特别高，结果它一直占着CPU，其他任务全被饿死了。后来我加了个vTaskDelay(1)，让它在每次循环里主动让出CPU，问题就解决了。

总结几条实战建议：

优先级从低往高设：先让所有任务都能跑起来，再逐步提高关键任务的优先级
同优先级任务不要太多：超过3-4个同优先级任务，时间片轮转的效率会下降
高优先级任务要“快进快出”：处理完紧急事件就阻塞或延时，别占着CPU不放
用工具分析调度情况：比如FreeRTOS的Tracealyzer，能直观看到任务切换和优先级反转

好了，这一章的内容就到这里。抢占式调度、时间片轮转、优先级设计，这三者是RTOS调度的基石。你想想看，把这些搞明白了，扫地机里几十个任务的调度问题，基本都能应对。

下一章我们讲任务间通信——队列和信号量。到时候我会分享一个我调试过的“消息丢失”的案例，很有意思。咱们下章见。

📚 课程目录