23、实时系统与并发：实时调度策略、优先级反转与解决、锁的实时性影响、RTOS中的并发原语

聊到实时系统，很多做应用层开发的朋友会觉得有点遥远。其实不然。你想想看，自动驾驶的决策模块、工业机器人的关节控制、甚至你手里的无人机飞控——这些系统一旦出问题，可不是界面卡顿那么简单，那是要出事故的。

我最早接触实时系统是在一个医疗设备项目里。那个设备需要在1毫秒内响应传感器中断，否则病人数据就会丢失。嗯，那次经历让我彻底明白了：普通Linux上的pthread调度，跟真正的实时调度，完全是两码事。

实时调度策略：谁先跑，谁后跑？

实时调度策略，说白了就是决定「哪个任务现在该上CPU」。普通系统讲究公平，实时系统讲究「deadline第一」。

常见的实时调度策略有这么几种：

调度策略	核心思想	适用场景
Rate-Monotonic Scheduling (RMS)	周期越短，优先级越高	固定周期任务集
Earliest Deadline First (EDF)	截止时间越近，优先级越高	动态周期、非周期任务
Fixed-Priority Preemptive	静态优先级，高优先级抢占低优先级	大多数RTOS默认策略

我个人习惯在项目初期先用RMS做可行性分析。为什么？因为RMS的利用率测试公式简单：

U = Σ (Ci / Ti) ≤ n * (2^(1/n) - 1)

其中Ci是任务执行时间，Ti是周期，n是任务数。如果算出来U小于这个上限，那调度一定是可行的。我在一个6任务的项目里用过这个公式，算出来U=0.68，上限是0.73，心里就有底了。

但EDF更灵活。它允许CPU利用率接近100%。代价是什么？实现复杂，而且一旦过载，所有任务都可能错过deadline——这叫「多米诺效应」。RMS过载时至少低优先级的任务先挂，高优先级的还能保住。

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

优先级反转，我估计每个做实时系统的工程师都踩过。它的场景是这样的：

• 任务H（高优先级）想访问共享资源
• 任务L（低优先级）正占着这个资源
• 任务M（中优先级）不访问资源，但一直跑，把L给抢占了
• 结果：H等着L，L被M抢，H反而被M间接阻塞了

为什么会这样？因为L被M抢占后，没法释放锁。H优先级再高，也得等L重新上CPU才能解锁。这就像高速上的救护车被一辆慢车堵着，而慢车又被另一辆更慢的车堵着——优先级完全颠倒了。

我曾经在一个雷达信号处理项目里遇到过这个问题。一个高优先级的中断处理任务，偶尔会延迟几十毫秒。查了三天，最后发现是一个低优先级的日志任务占着锁不放，中间还有个中优先级的网络任务在抢CPU。嗯，那三天真是刻骨铭心。

解决方案：优先级继承与优先级天花板

解决优先级反转，主流方案有两个。

优先级继承：当高优先级任务被低优先级任务阻塞时，低优先级任务临时「继承」高优先级的优先级。这样中优先级的任务就抢不过它了。等锁释放后，低优先级任务恢复原优先级。

// 伪代码示例：优先级继承锁
void lock(pthread_mutex_t *mtx) {
    if (mtx->owner != NULL && mtx->owner->priority < current_task->priority) {
        // 临时提升持有者的优先级
        mtx->owner->priority = current_task->priority;
    }
    // 正常加锁逻辑...
}

void unlock(pthread_mutex_t *mtx) {
    // 恢复持有者的原始优先级
    mtx->owner->priority = mtx->owner->base_priority;
    // 正常解锁逻辑...
}

优先级天花板：给每个锁设定一个「天花板优先级」，等于所有可能获取该锁的任务中的最高优先级。任何任务获取锁时，它的优先级自动提升到天花板级别。这比优先级继承更简单，但可能过度提升优先级，造成一定的CPU浪费。

锁的实时性影响：别让锁成为瓶颈

锁在实时系统里是个双刃剑。没有锁，数据竞争；有了锁，可能阻塞。我见过一个项目，用了20多个锁，结果一个高优先级任务要等4个锁才能执行——延迟直接爆表。

锁对实时性的影响主要体现在三个方面：

1. 阻塞时间：高优先级任务等锁的时间，直接加到响应延迟里
2. 优先级反转：上面讲过了，锁越复杂，反转越严重
3. 上下文切换：锁竞争会导致频繁的线程切换，浪费CPU

怎么优化？我总结了几条实战经验：

• 减少锁的粒度：能用原子操作就别用锁，能用读写锁就别用互斥锁
• 锁内不要做耗时操作：比如I/O、内存分配、复杂的计算——这些都应该在锁外完成
• 考虑无锁数据结构：比如无锁队列、无锁哈希表，在实时场景下特别有用

RTOS中的并发原语

RTOS（实时操作系统）里的并发原语，跟通用OS不太一样。它们更轻量、更可预测。常见的包括：

原语	特点	典型用途
信号量 (Semaphore)	计数型，支持超时	资源池管理、事件通知
互斥量 (Mutex)	支持优先级继承	保护共享资源
消息队列 (Message Queue)	固定大小，FIFO或优先级排序	任务间通信
事件标志组 (Event Flags)	位掩码，支持多事件等待	同步多个条件

以FreeRTOS为例，它的互斥量实现就内置了优先级继承。你不需要自己写代码，直接调用xSemaphoreCreateMutex()就行。但要注意：RTOS里的API调用通常不能在中断服务函数里使用——除非是专门为中断设计的版本（比如xSemaphoreGiveFromISR()）。

我习惯在项目初期就画一张「并发原语使用图」，明确每个资源用什么原语保护、哪些任务会访问、优先级关系如何。这张图比代码本身更能帮你发现潜在的死锁和优先级反转问题。