第3章任务调度优化

3. 任务调度优化：抢占式调度与时间触发调度，优先级反转与解决策略

各位同学，咱们今天聊点硬核的——任务调度。说实话，我在做制导控制系统之前，一直觉得调度嘛，不就是给任务排个队？直到有一次，一枚试验弹在飞行中因为调度问题导致控制指令延迟了 3 毫秒……嗯，后果很严重。从那以后，我对调度这件事就再也不敢马虎了。

3.1 抢占式调度：谁急谁先跑

抢占式调度，说白了就是「高优先级任务可以打断低优先级任务」。这在实时系统里非常常见。你想想看，导弹飞行中，导引头数据处理肯定比日志记录要紧急得多，对吧？

我个人的习惯是，在制导系统中，把控制律计算、传感器数据采集这类硬实时任务设为最高优先级。而像遥测数据打包、健康监控这类软实时任务，优先级就放低一些。

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

每个任务都有一个固定的优先级
高优先级任务就绪时，立即抢占当前运行的较低优先级任务
被抢占的任务会保存上下文，等下次被调度时继续执行

举个例子，假设我们有一个简单的抢占式调度系统：

// 任务优先级定义
#define PRIO_GUIDANCE     90   // 制导控制任务 - 最高
#define PRIO_SENSOR       80   // 传感器采集任务
#define PRIO_TELEMETRY    30   // 遥测任务 - 最低

void task_guidance(void *arg) {
    while(1) {
        // 读取导引头数据
        // 计算制导指令
        // 输出到舵机
        vTaskDelay(5);  // 5ms周期
    }
}

void task_sensor(void *arg) {
    while(1) {
        // 采集IMU数据
        // 滤波处理
        vTaskDelay(10); // 10ms周期
    }
}

void task_telemetry(void *arg) {
    while(1) {
        // 打包遥测数据
        // 发送到地面
        vTaskDelay(100); // 100ms周期
    }
}

这里要注意，抢占式调度虽然响应快，但有个坑——优先级反转。我后面会详细讲。

3.2 时间触发调度：一切按计划来

时间触发调度，就是所有任务都在预先规划好的时间点执行。没有抢占，没有随机性。这种调度方式在航空电子系统中用得很多，比如 ARINC 653 标准。

我曾在某型导弹的飞控计算机上用过时间触发调度。说实话，刚开始觉得这玩意儿太死板了，后来发现它有个巨大的好处——可预测性极强。每个任务的开始时间、结束时间、最坏执行时间都是确定的。

时间触发调度的典型结构：

// 时间触发调度表
typedef struct {
    uint32_t start_time;   // 开始时间（微秒）
    uint32_t duration;     // 执行时长（微秒）
    void (*task_func)(void); // 任务函数指针
} TimeTriggeredTask;

// 调度表定义
TimeTriggeredTask schedule[] = {
    {0,     500,   task_sensor},      // 0-500us: 传感器采集
    {500,   1000,  task_guidance},    // 500-1500us: 制导计算
    {1500,  500,   task_actuator},    // 1500-2000us: 舵机控制
    {2000,  1000,  task_telemetry},   // 2000-3000us: 遥测
    // 总周期 3000us = 3ms
};

void time_triggered_scheduler(void) {
    uint32_t tick = get_system_tick();
    uint32_t slot = tick % TOTAL_CYCLE;
    
    for(int i = 0; i < NUM_TASKS; i++) {
        if(slot >= schedule[i].start_time &&
           slot < schedule[i].start_time + schedule[i].duration) {
            schedule[i].task_func();
            break;
        }
    }
}

嗯，这里有个关键点——时间触发调度要求所有任务的执行时间必须严格小于分配的时间槽。我曾经因为一个任务超时，导致后续所有任务都跟着偏移，整个调度表乱成一锅粥。所以，时间触发调度对代码的时序要求非常苛刻。

3.3 优先级反转：一个经典的坑

优先级反转，我愿称之为实时系统里最阴险的问题之一。它长什么样呢？

假设有三个任务：

任务A（高优先级）：需要访问共享资源R
任务B（中优先级）：不需要访问R，纯计算
任务C（低优先级）：正在使用资源R

正常情况下，A应该等C用完R后立即执行。但问题是——B来了！B的优先级比C高，所以B抢占了C。C还没释放R，A就只能干等着。而B呢？它在那儿悠哉悠哉地跑着。结果就是：高优先级的A，被中优先级的B给堵死了。

我在某次半实物仿真中就遇到过这个情况。导引头数据处理任务（高优先级）被一个日志记录任务（中优先级）堵了整整 20 毫秒。你想想看，20 毫秒在制导控制里意味着什么？导弹可能已经飞出去几十米了。

⚠️ 优先级反转的后果

在制导系统中，优先级反转可能导致：

控制指令延迟输出，影响飞行稳定性
传感器数据丢失，导致导航误差累积
最坏情况下，系统崩溃或任务失败

3.4 解决策略：别让高优先级任务等太久

解决优先级反转，业界有几种成熟方案。我挑最常用的两种讲。

3.4.1 优先级继承协议

这个协议的核心思想是：当低优先级任务持有高优先级任务需要的资源时，临时提升低优先级任务的优先级。

具体做法：

任务C（低优先级）获取了资源R
任务A（高优先级）请求资源R，被阻塞
系统检测到A在等C释放R，于是把C的优先级提升到和A一样
C继续执行，不会被B（中优先级）打断
C释放R后，优先级恢复原样
A拿到资源，开始执行

代码实现示例：

// 优先级继承的互斥锁实现
typedef struct {
    uint32_t owner_priority;   // 当前持有者的原始优先级
    uint32_t inherited_priority; // 继承后的优先级
    TaskHandle_t owner;        // 当前持有者
    bool locked;
} PriorityInheritanceMutex;

void mutex_lock(PriorityInheritanceMutex *m, TaskHandle_t task) {
    if(!m->locked) {
        m->locked = true;
        m->owner = task;
        m->owner_priority = get_task_priority(task);
        return;
    }
    
    // 检测优先级反转
    uint32_t req_prio = get_task_priority(task);
    if(req_prio < m->owner_priority) {
        // 高优先级任务在等待，提升持有者优先级
        m->inherited_priority = req_prio;
        set_task_priority(m->owner, req_prio);
    }
    
    // 阻塞当前任务
    block_task(task);
}

void mutex_unlock(PriorityInheritanceMutex *m) {
    // 恢复原始优先级
    set_task_priority(m->owner, m->owner_priority);
    m->locked = false;
    
    // 唤醒等待队列中的最高优先级任务
    wake_highest_priority_task();
}

💡 我的经验

优先级继承协议在大多数 RTOS 中都有现成实现。比如 FreeRTOS 的互斥量就默认支持优先级继承。我建议你直接用操作系统的原生机制，别自己手写——我曾经手写过一次，调试了整整两天才发现一个边界条件没处理好。

3.4.2 优先级天花板协议

这个协议更激进一些。它给每个共享资源设定一个「天花板优先级」——所有可能访问这个资源的任务中，最高的那个优先级。

当一个任务获取资源时，它的优先级会被临时提升到这个天花板级别。这样一来，任何比天花板优先级低的任务都无法抢占它。

举个例子：

资源	访问任务	天花板优先级
共享内存A	任务1(90), 任务2(70), 任务3(50)	90
串口B	任务2(70), 任务4(60)	70
CAN总线C	任务1(90), 任务5(80)	90

如果任务3（优先级50）获取了共享内存A，它的优先级会被提升到90。这时候，任何优先级低于90的任务（包括任务2、任务4等）都无法抢占它。直到它释放资源，优先级才恢复。

🔑 两种协议的对比

优先级继承：实现相对复杂，但更灵活，不会过度提升优先级。

优先级天花板：实现简单，但可能导致优先级提升过高，影响系统实时性。

我个人在制导系统中更倾向于优先级继承——因为制导任务优先级通常很高，过度提升反而可能影响其他关键任务。

3.5 实际项目中的选择建议

说了这么多，到底该用哪种调度方式？我根据经验给个参考：

抢占式调度 + 优先级继承：适合大多数制导控制系统。灵活，响应快，配合互斥量使用即可。
时间触发调度：适合对确定性要求极高的场景，比如飞行控制计算机、安全关键系统。代价是灵活性差，任务变更需要重新设计调度表。
混合调度：我最近在项目中尝试的做法。关键任务（制导、导航）用时间触发，非关键任务（日志、监控）用抢占式。效果还不错。

最后说一句——无论用哪种调度方式，一定要做最坏情况下的时序分析。我曾经因为偷懒没做分析，结果在极限工况下出了事。嗯，那次教训够我记一辈子。

好了，这一章就到这里。下一章我们聊聊中断管理——怎么在保证实时性的同时，不让中断把系统搞崩。