1、调度器概述：什么是任务调度、实时系统与非实时系统的区别、调度算法的评价指标

大家好，欢迎来到《RTOS内核之位图调度算法实现》的第一课。

我是你们的老朋友，一个在嵌入式领域摸爬滚打了十几年的工程师。今天咱们不聊虚的，直接切入正题——调度器。

说白了，调度器就是RTOS的“大脑”。你想想看，一个单片机里跑着好几个任务，谁先执行？谁后执行？谁该被暂停？这些决策，全得靠调度器来拍板。

1.1 什么是任务调度？

任务调度，简单理解就是“分时复用CPU”。

CPU只有一个，但任务可以有几十个。调度器的工作，就是决定在任意一个时刻，哪个任务能拿到CPU的使用权。

我习惯把调度器比作一个交通警察。任务就像路上的车，CPU就是十字路口。没有交警，车就会乱成一锅粥。有了调度器，每个任务才能有序地“通过路口”。

在RTOS里，每个任务都有自己的状态：

• 就绪态：任务准备好了，随时可以跑，就等CPU空闲。
• 运行态：任务正在占用CPU，执行代码。
• 阻塞态：任务在等某个事件，比如等一个信号量、等延时结束。
• 挂起态：任务被强制暂停，不参与调度。

调度器只关心“就绪态”的任务。它会从就绪队列里挑一个，让它进入运行态。

1.2 实时系统与非实时系统的区别

这个问题，我当年面试新人时经常问。很多人背过定义，但真到项目里就分不清了。

咱们直接说人话：

• 非实时系统：比如你用的Windows、Linux桌面版。你点一下鼠标，系统过个几百毫秒才响应，你也不会觉得有什么大问题。任务晚一点完成，没关系。
• 实时系统：比如汽车的安全气囊控制器。你撞车了，气囊必须在几毫秒内弹出。晚1毫秒，可能就是生与死的区别。

实时系统又分两种：

类型	特点	例子
硬实时	截止时间必须满足，否则系统崩溃或造成灾难	安全气囊、飞行控制器
软实时	偶尔错过截止时间可以接受，但性能会下降	视频播放器、音频处理

我在项目中遇到过一件事。有一次做工业机器人控制器，用了某个非实时的Linux方案。结果机械臂在高速运动时，偶尔会“卡顿”一下。嗯，就是那一下，工件直接报废了。后来换成了RTOS，用位图调度，问题才解决。

为什么会这样？因为非实时系统追求的是“平均性能”，而实时系统追求的是“最差情况下的确定性”。

1.3 调度算法的评价指标

评价一个调度算法好不好，不能光凭感觉。咱们得看几个硬指标。

1.3.1 吞吐量

吞吐量，就是单位时间内系统完成了多少任务。

举个例子：一个系统每秒能处理1000个网络包，另一个只能处理500个。前者的吞吐量更高。

但要注意，吞吐量高不代表实时性好。有些调度算法为了追求吞吐量，会让长任务一直占着CPU，短任务反而被饿死。

1.3.2 延迟

延迟，是实时系统最关心的指标。它又分两种：

• 响应时间：从任务被触发，到它开始执行的时间。
• 完成时间：从任务被触发，到它执行完毕的时间。

我习惯把延迟比作“你点外卖到吃上饭的时间”。响应时间就是“商家开始做菜的时间”，完成时间就是“你吃完的时间”。

在RTOS里，我们最怕的是“抖动”——就是每次的延迟都不一样。有时候1ms，有时候10ms。这种不确定性，对实时系统是致命的。

1.3.3 公平性

公平性，就是每个任务能不能得到“合理”的CPU时间。

你想想看，如果系统里有10个任务，其中一个优先级特别高，一直占着CPU。其他9个任务永远得不到执行——这叫“饥饿”。

好的调度算法，会尽量保证每个任务都能在合理的时间内得到执行。但注意，实时系统里“公平”不等于“平均”。高优先级的任务理应得到更多资源，这是合理的。

公平性通常用“最大饥饿时间”来衡量——就是最倒霉的那个任务，最长要等多久才能被执行。

指标	含义	实时系统关注度
吞吐量	单位时间完成任务数	中等
响应延迟	任务触发到开始执行	极高
完成延迟	任务触发到执行完毕	高
抖动	延迟的波动范围	极高
公平性	任务是否被饿死	高

好了，这一章的内容就到这里。咱们把调度器的基本概念、实时与非实时的区别、以及评价指标都捋了一遍。

下一章，我会带大家看看几种经典的调度算法——先来先服务、时间片轮转、优先级调度。然后咱们再聊聊，为什么位图调度能在实时性上胜出。

记住，调度器是RTOS的灵魂。理解它，你才能真正掌握嵌入式系统的精髓。

---

公众号:蓝海资料掘金营，微信deep3321