实时调度策略 SCHED_FIFO/SCHED_RR 与优先级抢占

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

实时调度概述

急诊室的病人并不都是“能等”的。心脏骤停的患者，晚一分钟处理就可能丧命；而一个脚踝扭伤的年轻人，在候诊室多坐半小时也没关系。操作系统里也有这样两类任务：一类是普通进程，晚几毫秒执行只是体验变差；另一类是实时任务，必须在规定时间内拿到结果，否则就是事故。判断一个任务是否“等不得”，看它有没有截止期限（deadline）就一目了然。

有截止期限不代表一定强求。现实中，“手术必须成功”是硬实时，错过期限等于失败；“外卖 30 分钟内送到”是软实时，超时几分钟还能接受，只是体验打折。Linux 的实时调度器并不区分这两者，它只负责一件事：让所有挂了红牌的任务，尽可能在期限内完成。

但医生只有一个，病人却很多。能不能安排得过来，有一个经典的利用率判据：

所以调度器的一切设计，都是在“医生不够用”这个前提下展开的。剩下的问题只有一个：怎样保证最等不及的病人先被照顾到？这就引出了急诊室的第一个工具——优先级牌子。

优先级机制

急诊室不会让所有病人排成一条长队。分诊护士会先给每个人挂上牌子：红牌是危重，立刻抢救；黄牌是较重，尽快处理；绿牌是轻症，排队等着。操作系统也一样，每个进程和线程都有一块“紧急牌”，名字叫优先级（priority）。调度器每次选人，先看牌子再看顺序。

在 Linux 中，实时调度的优先级是 1 到 99 之间的整数，数值越大，紧急程度越高，99 就是最高级别的红牌。这与普通进程的 nice 值正好相反——nice 的取值范围是 -20 到 19，数值越小优先级越高。两套规则方向不同，初学者最容易在这里栽跟头。

给病人挂红牌，在代码里是通过系统调用来完成的：

牌子挂对了，医生才能在关键时刻认出谁最该救。可是“先救谁”只是第一步，另一个问题是：救到什么程度才换人？这就轮到 SCHED_FIFO 出场了。

FIFO运行策略

想象一位主刀医生：只要上了手术台，就必须把整台手术做完才下台。中途既不会因为“到点了”就换人，也不会因为来了个同级别的病人就停手。这种“一鼓作气”的风格，就是 SCHED_FIFO（First In First Out，先来先服务）的写照。

严格来说，FIFO 根本没有“时间片”这个概念。一个 FIFO 任务只要还能运行，就会一直霸占 CPU，直到发生以下三种情况之一：任务自己调用 sched_yield() 主动让出；任务阻塞，比如等待键盘输入或磁盘数据；来了一个更高优先级的任务，把它强行抢走。除此之外，没有任何机制会打断它。

用公式描述它“一口气能跑多久”：

FIFO 最适合那些“要么一次做完、要么出错”的紧要活儿。但凡事有两面：几个同样紧急的病人同时在场时，医生总抓着一个人不放，其他人会不会有意见？于是就有了第二套规则——SCHED_RR。

RR轮转策略

SCHED_RR（Round Robin，时间片轮转）像门诊叫号：每位病人限时 3 分钟，不管看完没看完，到点必须起身换下一位。所有拿着同色牌子的病人在一个圈里轮流坐庄，谁也别想独占医生。

RR 与 FIFO 的唯一区别，就是给同优先级任务加了一个时间片。Linux 中 SCHED_RR 的默认时间片是 100ms，代码里可以用 sched_rr_get_interval() 查到实际值。时间片用完而任务还没结束，它就被挪到同优先级队列的末尾，等下一圈。注意一个关键点：低优先级任务不会因此受益——RR 只在同一个优先级组内轮转，红牌病人的圈子里不会出现绿牌病人。

时间片模型用公式表达就是：

RR 的价值是“雨露均沾”：几个同等紧急的任务，谁也别想独占医生。但急诊室还有最后一条铁律没讲——如果抢救进行到一半，突然推进来一个牌子更红的病人呢？

优先级抢占

急诊室的墙上贴着一条铁律：无论医生正在给谁看，只要推进来一位牌子更红的病人，医生必须立刻放下手里的一切冲过去。不许说“等我做完这台手术”，也不许说“等下一个整点”。这条铁律，在操作系统里就是“抢占”（preemption）。

抢占的条件只有一条：新就绪任务的优先级 > 当前运行任务的优先级。反过来也成立一条推论：相同优先级的任务之间互不抢占。FIFO 任务之间靠“自觉”——前面的做完或让出，后面的才能上；同组 RR 任务之间靠时间片来换手。谁也不会去抢平级同事的活儿。

抢占这个动作可以用逻辑式表示：

有了抢占铁律，“红牌优先”才真正落地。但这里还有一个隐藏问题：医生换人很快，可医生是怎么在几十个候诊病人里“一眼锁定”最红牌子的呢？答案就藏在急诊室后台的分诊台里。

运行队列切换

急诊室后台有一张巨大的分诊台，上面按红、黄、绿分区陈列着所有等待的病人。操作系统里这张台子叫运行队列（runqueue），每个 CPU 一张，专门维护“就绪但还没轮上”的实时任务。台子的设计直接决定了叫号的速度。

在 Linux 中，实时运行队列由“优先级位图 + 链表数组”构成：每个优先级对应一条队列，位图的每一位标记该队列是否为空。要找到下一个该谁上场，只需从最高位往下扫，找到第一个“非空”的位。这个操作只需一条 CPU 指令，复杂度是 O(1)，与任务总数无关——无论候诊室挤了 10 个人还是 1000 个人，找最紧急病人的时间都一样。

查找动作的公式化表示：

分诊台的效率保证了“叫号”几乎不浪费时间。但理论归理论，真实系统里怎么给进程挂红牌、怎么配置调度策略？下一个环节，我们进入实操。

实践配置工具

挂红牌不是喊口号，得有趁手的工具。Linux 命令行里最常用的是 chrt 命令：chrt -f -p 80 1234 表示把 PID 为 1234 的进程设为 SCHED_FIFO、优先级 80；chrt -r -p 50 5678 则表示设为 SCHED_RR、优先级 50。一条命令，立竿见影。

在程序代码里设置实时属性，通常通过 pthread 线程属性完成。创建线程之前，先设置一个“挂号单模板”：模板上写好接诊规则和优先级，再把这套模板交给 pthread_create。设置动作发生在创建之前，创建出来的线程才是实时线程，这一点非常容易踩坑。

线程属性的设置过程：

工具和 API 是把调度理论搬进生产系统的“挂号窗口”。但窗口排对了，急诊室依然可能翻车——下一节我们看看最著名的几起“医疗事故”。

风险与优化

急诊室也会翻车。最经典的翻车场面叫“优先级反转”：低优先级病人 A 手里紧紧攥着一把手术钳（锁），高优先级病人 B 正等着这把钳子做手术，中优先级病人 C 却不停来抢医生。结果 B 这个最该先救的，反而被 C 拖得最惨——这就是反转。

Linux 的经典解法是“优先级继承”：当 B 在等待 A 的锁时，A 临时升级到 B 的红牌号，先把手术做完交还钳子再恢复原级别。C 看到 A 的牌子变红，就不敢再来抢了。除了反转，还要警惕“饥饿”：一个 99 级的任务永远就绪，其他任务就永远饿着。这两种风险都是实时系统的“慢性病”。

反转场景可以浓缩成一行公式：

急诊室的智慧不是“见人就救”，而是有秩序地救。理解了 FIFO、RR 和抢占这三套规则的边界，你就能设计出真正可靠的实时系统。

AI 应用场景

Python 演示

#!/usr/bin/env python3# -*- coding: utf-8 -*-"""模拟 Linux 实时调度 SCHED_FIFO 与 SCHED_RR，并演示高优先级抢占。"""  class Task:    def __init__(self, name, priority, need, arrive=0):        self.name = name        self.priority = priority      # Linux 实时优先级 1~99，越大越紧急        self.need = need              # 还需的 CPU 时间（以时间片为单位）        self.arrive = arrive          # 到达（变为就绪）的时刻  def simulate(tasks, policy, quantum=3):    """逐步模拟调度，返回 [(时刻, 任务名), ...] 的切换序列。"""    state = {t.name: [t.need, t.priority, t.arrive] for t in tasks}    total = sum(t.need for t in tasks)    clock, served, cur, used = 0, 0, None, 0    timeline = []     def ready():        return sorted(            (n for n, d in state.items() if d[0] > 0 and d[2] <= clock),            key=lambda n: (-state[n][1], n))     while served < total:        pool = ready()        if not pool:            clock += 1            continue        nxt = pool[0]        if cur is None or nxt != cur:   # 切换（可能是高优先级抢占）            timeline.append((clock, nxt))            cur, used = nxt, 0        state[cur][0] -= 1        served += 1        clock += 1        used += 1        if policy == "RR" and state[cur][0] > 0 and used >= quantum:            same = [n for n in pool if state[n][1] == state[cur][1]]            if len(same) > 1:           # 同优先级内轮转到下一位                cur = same[(same.index(cur) + 1) % len(same)]                timeline.append((clock, cur))                used = 0        elif policy == "FIFO" and state[cur][0] == 0:            cur = None                  # 当前任务完成，重新挑选    return timeline  def show(title, timeline):    seg, start, buf = None, 0, []    for t, name in timeline:        if name != seg:            if seg is not None:                buf.append("%s@%d-%d" % (seg, start, t - 1))            start, seg = t, name    buf.append("%s@%d-%d" % (seg, start, timeline[-1][0]))    print(title + ": " + " -> ".join(buf))  def main():    tasks = [        Task("P1A", 95, 6),        Task("P1B", 95, 6),        # 与 P1A 同优先级，观察 RR 轮转        Task("P2", 50, 8),        Task("Alarm", 99, 3, 4),   # 第 4 时刻到达的危重任务，演示抢占    ]    show("SCHED_FIFO", simulate(tasks, "FIFO"))    show("SCHED_RR  ", simulate(tasks, "RR", quantum=3))  if __name__ == "__main__":    main()

1. key=lambda n: (-state[n][1], n)把就绪任务按实时优先级从高到低排序，同优先级按名字取稳定顺序，模拟分诊台“先挑最红牌子”。
2. if cur is None or nxt != cur:发现候选人不是当前任务，就是一次调度切换；可能是正常换班，也可能是高优先级任务到达触发抢占。
3. timeline.append((clock, nxt))记录每次切换的时刻与任务名，最后用 show() 输出分段运行序列。
4. if policy == "RR" and state[cur][0] > 0 and used >= quantum:RR 的关键：时间片耗尽且任务没做完，就要在同优先级组内换人。
5. same[(same.index(cur) + 1) % len(same)]在同优先级组里取“下一位”，构成轮转环。
6. elif policy == "FIFO" and state[cur][0] == 0:FIFO 的关键：任务没做完就一直占用 CPU，只有做完了才重新挑选。

常见误区

面试题