深度拆解RTOS任务调度：从就绪表到上下文切换的完整链路

做嵌入式的人，谁还没点过灯呢。从裸机环境下写个while(1)让LED闪起来，到后来用定时器、状态机把闪烁节奏梳理得明明白白，再到某天你打开FreeRTOS的例程，看到xTaskCreate、vTaskDelay这些API，一个念头肯定会冒出来：我压根没主动调用任何函数，操作系统是怎么知道该让哪个任务上场的？背后到底是谁在做“选角”？

别一听到“任务调度”就联想到后端那套分布式任务调度平台，这里说的是单片机里那个几KB内存就能跑起来的实时操作系统（RTOS）。这篇文章就是把RTOS任务调度这条链彻底拆开聊：任务是怎么被“选中”的、选完之后CPU是怎么“变装”切过去的、第一次启动切换又是怎么点火的。如果你在用RTOS但还没看过内核、或者面试被问“任务调度原理”只能背概念，那这篇应该对你有用。我会从手搓一个精简RTOS的视角来讲，你会发现调度器本质上就是一套“选角逻辑+换装流程”，而CPU就是那个只有一个位置的后台化妆间。

1. 先搞明白：调度器到底在安排什么

1.1 任务不是一个函数，而是一条“有状态的执行流”

很多刚接触RTOS的人有一个误解：任务就是那个函数名。你说task_led、task_key，不就是两个函数嘛，跟裸机里main()调用子函数有什么区别？

区别大了。裸机编程里，main()的while(1)调用各个子函数，函数调用靠C语言的调用栈维护——调用a()时把返回地址压栈，a()返回时弹栈回到调用点。这是顺序执行，CPU永远沿着一条路走到底，不存在“干了一半被踹下去、过会儿再回来接着干”的情况。

但RTOS不一样。它让你可以“假装”同时跑好几个任务：task1点灯，task2读按键，task3刷显示。CPU只有一个，凭什么能同时干三件事？答案是分时复用——每个任务跑一小段时间，然后被换下去，另一个任务换上来。而“换”这个动作不是函数返回，而是把整个执行现场（寄存器、栈、状态）保存下来，再恢复另一个任务的现场。

所以，任务在RTOS里真正对应的是三样东西：

• 独立的栈空间，用来保存局部变量、函数调用链；
• 寄存器快照，用来保存CPU现场；
• 一个任务控制块，用来保存任务的属性、状态、优先级。

这三样缺一不可。很多人理解不了调度，正是因为只盯着那个函数名，把“栈”和“现场”这两个关键信息丢了。

1.2 调度器就是那个“选角导演”

把CPU想成一个舞台，任务就是一群等着上台的演员。舞台只有一个，谁先上、上多久、什么时候下台，必须有一个统一的规则。这个规则的执行者就是调度器（Scheduler）。

不同RTOS的调度风格不太一样：FreeRTOS默认是优先级抢占加同优先级时间片轮转；uC/OS-III也支持时间片轮转；RT-Thread同样是优先级抢占加时间片。也有一些学术味更重的实时调度算法，比如RMS、EDF，但你在实际嵌入式项目里最常碰到的，其实就是“优先级抢占 + 时间片轮转”这套组合。

调度时机（什么时候“选角”）通常分两类：

1. 主动让出：任务自己调用延时、等待信号量、等待队列消息，主动说自己暂时不上台了。
2. 被动抢占：更高优先级的任务就绪了（比如在中断里被唤醒），或者时间片用完了，调度器把当前任务赶下去，换另一个上来。

这两种时机听起来不难，但落成代码之后，要解决的是“在哪里调用调度器”和“调度器怎么选人”这两个问题。后面会逐一展开。

1.3 从点灯到RTOS，为什么要手搓一遍

市面上现成的RTOS一抓一大把，FreeRTOS移植几行代码就能跑，为什么还要自己写调度器？

我的看法是，手搓操作系统的目的从来不是为了替代FreeRTOS，而是为了把黑盒变白盒。我自己在用FreeRTOS写了好几个项目之后，任务创建、信号量、消息队列都门儿清，可一被问“任务是怎么从就绪列表里被选出来的”，就卡壳了。直到自己实现了一遍，才发现核心就几个点：优先级位图找最高优先级、PendSV异常做上下文切换、SysTick做时间基准。这几个点通了之后，再去读FreeRTOS源码，会发现它不过是在这个骨架上堆了大量工程化细节——内存管理、任务通知、软件定时器、事件链、调试辅助等。那个真正的“调度内核”，就是这篇文章要讲的东西。

所以这篇的路线是：先讲调度器的数据结构，再讲“选角算法”，然后讲“换装流程”，最后落地到启动切换和常见调试坑。跟着走一遍，你对RTOS的理解会上一个台阶，面试也能从“背概念”变成“讲原理”。

2. 核心数据结构：任务控制块（TCB）与就绪表

2.1 TCB：任务的“身份证+档案袋”

既然任务是一个可以暂停/恢复的执行流，那操作系统必须有一个数据结构保存它的全部信息。这个结构就是任务控制块（Task Control Block，TCB），有的RTOS叫任务块，也有叫进程控制块（PCB）的。名字无所谓，本质一样。

自己实现一个简化版TCB，字段大致长这样：

typedef struct tcb { uint32_t *sp; // 栈指针：任务被换下时保存现场的位置 uint8_t priority; // 优先级，数字越小优先级越高 uint8_t state; // 状态：就绪、阻塞、挂起、运行 void (*entry)(void *arg); // 任务入口函数 void *arg; // 入口参数 uint32_t stack_size; // 栈大小（字节） uint32_t slice_ticks; // 时间片剩余计数（同优先级轮转用） struct tcb *next; // 链表节点，可挂到就绪表/延时表/等待表 } TCB;

几个关键字段单独说：

• sp是整个TCB里最核心的字段。任务被换下时，CPU当前栈指针的值要存到sp里；任务被换上时，再把sp的值恢复到CPU，任务就能从上一次暂停的位置继续跑。
• priority决定了任务的插队权，调度器每次选人都会读它。
• state用来区分任务此时待在哪张表里：就绪任务在就绪表，延时任务在延时表，等信号量的任务在等待表。
• 实际工程里，FreeRTOS的TCB比这个复杂得多，还有事件等待、任务通知、栈起始地址等，但核心思路是一样的。

TCB在项目里通常是一个静态数组，不会用malloc动态分配，因为嵌入式环境要避免堆碎片：

static TCB task_tcb[OS_MAX_TASKS];

任务创建函数做的事情，本质就是初始化一个TCB：传入入口函数、优先级、栈空间，然后把栈指针初始化成“假装刚被打断过的状态”。这个细节后面专门讲，它是第一次任务切换能成功的前提。

2.2 就绪表：谁在等待上台

有了TCB，调度器还得知道“现在有哪些任务是想上台的”。这个集合就是就绪表（Ready Table）或就绪队列。

最朴素的实现是链表：把所有state为就绪的TCB串起来，调度时遍历链表找优先级最高的。代码确实简单，但两个问题很要命：

• 时间复杂度O(n)，任务多了之后，每次调度都要从头遍历；
• 链表的插入摘除操作容易出指针错误，排错很花时间。

更常见、也几乎成了业界标准的方案是“优先级位图 + 就绪表数组”。假设系统支持32个优先级，就绪表就是一个32位变量：

volatile uint32_t ready_bitmap; // 每个bit=1，表示对应优先级至少有任务就绪

每个bit位对应一个优先级，1表示这个优先级有任务在等。如果同优先级允许多个任务（时间片轮转），就需要再加一层：每个优先级挂一个链表，把同优先级的就绪任务串起来。

typedef struct { TCB *head; // 该优先级第一个就绪任务 TCB *tail; } ready_list_t; static ready_list_t ready_list[OS_PRIORITY_LEVELS]; static uint32_t ready_bitmap;

任务就绪时，挂到对应优先级的链表尾部，同时把ready_bitmap的对应bit置1。任务阻塞时，从链表摘除，如果链表空了，就把对应的bit清掉。这个结构的好处是：调度器不需要遍历所有任务，只需要看位图就知道最高优先级在哪。

2.3 优先级位图：用一条指令找到“最高优先级”

就绪表准备好了，“选角”的关键就变成了：怎么快速找到ready_bitmap里最高优先级的那个1？

这里有一个非常经典的优化——用硬件指令找最高位。在ARM Cortex-M上，CLZ指令（Count Leading Zeros，数前导零）一条指令就能算出最高位在第几，CMSIS里直接封装好了：

uint8_t get_highest_priority(void) { return 31 - __CLZ(ready_bitmap); }

__CLZ返回的是有多少个前导0。比如ready_bitmap的二进制是那种“高位有几个0然后出现1”的形态，最高位的1在哪，一条指令就出来了。这个操作是O(1)，跟任务数量完全无关。

如果不用硬件指令，查表法也可以。把256种情况的最高位预先算好，存一张表，32位数据拆成4字节分别查。这是老嵌入式工程师常干的事，但在Cortex-M上直接__CLZ就完事了，简洁很多。

到这里，“选角”的核心逻辑已经清晰了：调度器从来不是“遍历所有任务去比优先级”，而是通过位图快速定位最高优先级，再从该优先级对应的链表头取出下一个该上台的任务。这个“位图+链表”的结构，FreeRTOS、RT-Thread等主流RTOS都在用。掌握了它，你再去读源码，会发现很多代码眼熟得不行。

3. 调度算法：任务究竟是怎么被“选中”的

3.1 优先级抢占：最高优先级永远“插队”

现在进入正题：调度器到底怎么选任务。

优先级抢占（Preemptive Priority Scheduling）是RTOS最核心的规则，一句话：只要更高优先级的任务就绪了，当前正在运行的任务必须立刻下台，把CPU让出来。

这句话里有两个关键动作。

第一个，“更高优先级任务就绪”这个事件从哪儿来？最常见的是中断。比如串口收到一帧数据，中断服务程序里释放信号量或者往队列里发消息，这个动作把之前阻塞在信号量上的高优先级任务唤醒，它的state变成就绪，被插入就绪表。这时调度器就需要介入了。

第二个，“立刻下台”不是等当前任务自己调用delay，而是调度器在某个安全切换点强制执行。在Cortex-M上，这个安全切换点就是PendSV异常。中断服务程序返回后，不会直接回到被打断的任务，而是先进入PendSV，在那里完成上下文的切换。

一个典型的抢占场景是这么走的：

低优先级任务Task_Low正在运行 → 串口中断发生 → 中断里释放信号量，唤醒高优先级任务Task_High → 中断服务程序结束 → 调度器检查：Task_High优先级更高 → 触发PendSV，保存Task_Low现场，恢复Task_High现场 → Task_High开始运行

整个过程里，Task_Low完全没有“反抗”的机会，它甚至不知道自己被换下去了。等Task_High阻塞了，比如等待下一帧数据，调度器再把Task_Low的现场恢复，Task_Low继续跑，感觉就像“打了个盹”。

3.2 时间片轮转：同级任务的“轮流上台”

如果就绪表里同时有两个优先级相同的任务，怎么办？谁先上？

答案是时间片轮转（Round Robin）。每个任务分配一个时间片（通常是几个tick，比如FreeRTOS默认的configTICK_RATE_HZ是1000Hz，一个tick是1ms，时间片就是几个tick）。任务运行满一个时间片后，如果同优先级还有别的任务在等，就把它换下去，换下一个同级任务上来。

时间片的检查和切换在SysTick时钟节拍中断里做。SysTick每个tick触发一次中断，中断里通常干三件事：

1. 更新延时列表，把延时到期的任务重新加入就绪表；
2. 把当前运行任务的slice_ticks减1，如果减到0且同优先级链表里还有其他任务，就触发切换；
3. 检查“当前运行任务是否还是最高优先级最高的”，不是的话就触发抢占。

这里有个容易忽略的点：时间片轮转只在同优先级之间有实际意义。如果当前任务是全局最高优先级，而且没有同级竞争者，那即使slice_ticks归零，也没必要切换。所以调度器在SysTick里要先判断“有没有必要切换”，没必要就省下一次PendSV的开销。别小看这个判断，低功耗场景下，少一次无效切换能省不少电。

3.3 空闲任务：没人上台时的“替补演员”

稍微了解过RTOS的都知道，几乎所有RTOS都会自动创建“空闲任务”（Idle Task），它的优先级通常是最低的。

空闲任务存在的意义很实际：

• 当所有任务都阻塞时，比如都在等信号量、都在延时，总得有个任务在跑。CPU不能空转，否则没地方更新统计、清看门狗、回收资源。
• 空闲任务一般是个无限循环，里面可以做低优先级的维护工作。
• FreeRTOS的空闲任务还负责释放被删除任务的内存。

自己手写RTOS时，空闲任务强烈建议一定要建。原因很简单：调度器从就绪表选任务时，如果就绪表是空的，调度函数就会无任务可切，程序直接跑飞。有一个永远就绪的空闲任务在最低位兜底，调度器永远不会选空。这属于那种“平时感受不到、拆了立刻出事”的设计。

4. 上下文切换：任务上台的“变装”过程

4.1 为什么要保存现场：寄存器是“共享的更衣室”

先打个比方。CPU是一个单人更衣室，所有任务演员共用这个更衣室换装。任务A演到一半被叫下台，它不能把假发、道具留在更衣室里不管，因为下一个任务B上台要用同一个更衣室。A必须把自己的“随身物品”全部带走，B上台时再带上自己的“随身物品”。

CPU的“随身物品”就是寄存器。在Cortex-M3/M4上，通用寄存器有R0-R12、SP、LR、PC、xPSR等。任务切换要保证：任务A被换下时，它用过的寄存器值全部保存；任务B被换上时，B上次保存的寄存器值全部恢复。这样A和B都能“无缝续演”。

保存到哪里？答案是任务自己的栈。每个任务有独立的栈空间，寄存器快照全部压进自己的栈。这样“更衣室”本身（CPU寄存器）可以被反复复用，而每个演员（任务）的道具都放在自己的储物柜（任务栈）里。

4.2 PendSV：专为上下文切换设计的“安全通道”

在Cortex-M上，上下文切换不能随便找地方做，因为有些寄存器是硬件自动压栈，有些需要软件手动压栈，而且切换时机必须安全。

Cortex-M处理器专门设计了一个用于上下文切换的异常：PendSV（可挂起的系统服务异常）。它有两个特点：

1. 可以被软件挂起，等系统空闲时再执行；
2. 优先级可以设置为最低。

为什么切换要用PendSV而不是直接在SVC或者SysTick里做？因为：

• 如果在中断服务程序里直接做切换，可能打断另一个中断，导致中断延时变长，实时性就崩了；
• 把PendSV优先级设最低，它会等所有中断处理完、SysTick也处理完之后才执行。这样上下文切换永远不会打断中断服务程序。

所以主流RTOS在Cortex-M上的切换流程是标准化的：需要切换时，软件置位PendSV；等高优先级中断都处理完，进入PendSV；在PendSV里完成“旧任务现场保存+新任务现场恢复”。

4.3 切换流程拆解：一段必须用汇编写的过程

上下文切换的代码用C语言写不出来，必须用汇编。因为C编译器不知道你要操作PSP、要手动压栈R4-R11这些特殊场景。

这是一段Cortex-M上的PendSV处理函数核心汇编，加中文注释：

__asm void PendSV_Handler(void) { // 1. 获取当前任务的任务栈指针（线程模式使用PSP） MRS R0, PSP // 2. 手动保存 R4-R11 到当前任务栈，同时更新栈指针 STMDB R0!, {R4-R11} // 3. 把更新后的栈指针保存到当前任务TCB的sp字段 // （current_tcb是当前任务TCB指针的全局变量） LDR R1, =current_tcb LDR R1, [R1] STR R0, [R1] // 4. 调用调度函数，选出下一个要运行的任务 // 返回后R0指向下一个任务的TCB BL schedule_next_task // 5. 更新 current_tcb 指向新任务 LDR R1, =current_tcb STR R0, [R1] // 6. 从新任务的TCB获取栈指针，恢复R4-R11 LDR R0, [R0] LDMIA R0!, {R4-R11} // 7. 把新栈指针写回PSP，后续BX LR返回时， // 硬件自动从新栈中弹出 xPSR、PC、LR、R12、R3-R0 MSR PSP, R0 ORR LR, LR, #0x04 // 确保返回后使用PSP（线程模式） BX LR }

这段汇编值得反复看几遍，几个关键点：

• 第1到第3行是“保存旧任务现场”。注意Cortex-M在进入异常时，硬件已经把xPSR、PC、LR、R12、R3-R0这8个寄存器自动压栈到PSP了，所以这里只需要软件手动保存R4-R11。
• 第4行调用C函数schedule_next_task，这个函数用前面讲的“位图+链表”找下一个任务，返回它的TCB指针。
• 第6行开始是“恢复新任务现场”。先手动恢复R4-R11，剩下的8个寄存器由硬件在异常返回时自动弹栈。
• 整个流程不需要手动改PC，因为异常返回时栈里的PC值就是任务上次被中断时的下一条指令地址。

还有一个细节很多人没注意：为什么用PSP而不是MSP？Cortex-M有两种栈指针：MSP（主栈指针）用于中断和异常模式，PSP（进程栈指针）用于线程模式。RTOS让每个任务运行在线程模式，使用PSP，这样每个任务有自己的栈；而中断统一使用MSP，不走任务的栈，互不干扰。这个设计非常巧妙，理解它之后再看切换代码，很多疑惑会瞬间解开。

5. 调度器的启动与第一次切换

5.1 创建任务时，栈里到底放了什么

前面反复提到，任务创建时要初始化任务栈，让它看起来像“刚被中断过的样子”。为什么要这样？

因为第一次切换到该任务时，走的也是PendSV切换流程：从TCB里恢复栈指针，然后弹出寄存器，最后“异常返回”到任务的入口函数。所以任务创建时，栈里必须预先填好“异常返回时会用到的数据”。

具体来说，任务栈的初始布局是这样的（从高地址到低地址）：

对应到代码，任务栈初始化函数大致如此：

void task_stack_init(TCB *tcb, void (*entry)(void *arg), void *arg) { uint32_t *stack = (uint32_t *)((uint8_t *)tcb->stack_base + tcb->stack_size); // 模拟“异常自动压栈”后的布局 *(--stack) = 0x01000000; // xPSR（Thumb位=1） *(--stack) = (uint32_t)entry; // PC：任务入口 *(--stack) = 0x00000000; // LR：任务不应返回，填0 *(--stack) = 0x00000000; // R12 *(--stack) = 0x00000000; // R3 *(--stack) = 0x00000000; // R2 *(--stack) = 0x00000000; // R1 *(--stack) = (uint32_t)arg; // R0：第一个参数 // 模拟“手动压栈R4-R11”后的布局 for (int i = 0; i < 8; i++) { *(--stack) = 0x00000000; } tcb->sp = stack; // 初始化后的栈指针存到TCB }

注意LR填0这个细节。任务函数理应是无限循环，正常不会返回。如果因为bug任务函数return了，PC会跳到LR指向的位置。很多RTOS会把这里指向一个“任务错误处理”函数，比如死循环或断言，方便排查问题。简化版直接填0，一旦返回就会触发HardFault，也算一种“强制暴露bug”的策略——总比静默跑飞好。

5.2 第一次切换：调度器是怎么“点火”的

系统上电后，main函数里创建了几个任务，但此时CPU还在跑main，没有进入任何任务。要启动调度器，需要一次“最初的切换”，把CPU从main手里交到第一个任务手里。

这一步在Cortex-M上通常用SVC（系统服务调用）实现。SVC异常的设计初衷就是“用户主动触发内核服务”。启动调度器的流程：

1. 关中断，防止切换过程中被SysTick打断；
2. 触发SVC，进入SVC_Handler；
3. 在SVC_Handler里调用schedule_next_task，选出第一个任务（其实就是就绪表里最高优先级的那个）；
4. 把这个任务的TCB初始化到当前上下文，直接恢复现场；
5. 异常返回，CPU开始执行第一个任务。

第一次切换不用SVC、直接调用PendSV，理论上也能跑，但SVC语义上更规范。FreeRTOS的port代码里就是先vPortStartFirstTask配合SVC完成第一次切换的。

第一次切换之后，调度器才算真正“运转起来”。后面每次任务切换，走的都是SysTick触发、PendSV执行的路径。

5.3 时钟节拍：让调度器“活”起来的脉搏

调度器不能只在任务主动让出时才切换，那样高优先级任务就绪了也没人管。所以RTOS需要一个周期性的中断来“唤醒”调度器，这个中断叫时钟节拍（Tick），Cortex-M上通常用SysTick实现。

SysTick中断每个tick要做的事，前面提过：维护延时列表、维护时间片、检查是否需要调度。这里重点说延时是怎么实现的。

每个任务在延时时，会把自己的TCB挂到一张延时表里，同时记录“还需要多少个tick”。SysTick中断里统一把延时表中的计数减1，减到0的任务从延时表移到就绪表。所以vTaskDelay的精度取决于tick周期，比如tick配置为1ms，那延时精度就是1ms级别，这解释了“为什么RTOS延时不是纳秒级精确”的问题。

延时列表通常也按优先级顺序组织，或者直接用一个或多个链表。最早到期的任务排在前面，SysTick每次只检查链头，就能减少无效遍历。

还有一个优先级设置的坑：SysTick和PendSV的优先级谁高谁低？SysTick不能太低，否则节拍精度受影响；PendSV必须最低，否则它可能在中途打断中断服务程序。常见做法是SysTick优先级中等偏高、PendSV设最低。FreeRTOS的port宏里写得很清楚，动手移植时照着配就行。

6. 常见问题与调试实录

6.1 任务死活不切换：先查两个地方

自己做RTOS，最常见的现象是：创建了两个任务，结果只有一个在跑，另一个连一次都没被执行过。排查顺序一般是这样的：

第一步，查就绪表。创建任务时，有没有正确挂到就绪表里？优先级有没有设对？如果两个任务优先级相同，有没有使能时间片轮转？如果你根本没实现同优先级切换，那同优先级任务跑完第一个，第二个自然永远轮不上。

第二步，查调度时机。就算任务已经在就绪表里，如果没有事件触发调度器——没有中断、没有主动delay、没有信号量操作——当前任务就会一直占着CPU，另一个任务永远没机会。最简单的验证方法：每个任务函数里调用一个延时函数让出CPU。能切过去，说明调度逻辑基本通；切不过去，就在调试器里看schedule_next_task返回的到底是哪个TCB。

我在实际调试里经常用J-Link的RTT或者串口打印TCB指针来确认“当前在跑谁”。这个方法土，但非常管用。

6.2 栈溢出与“神秘重启”

手写RTOS时，栈问题是最阴间的bug。任务栈太小，PC指针跑飞，程序进HardFault或直接复位，而且往往没规律，优化等级一开就更难查。

我的排查方法是三管齐下：

• 创建任务时把整个栈区填一个固定魔数，比如0xDEADBEEF，跑一段时间后检查栈的高水位线，看哪些栈被用得快满了。很多RTOS内核自带的栈统计就是这么干的。
• 在HardFault_Handler里打断点，查看现场。如果PC指针指向奇怪地址，或者SP的值落在某个任务栈范围内，基本能锁定是哪个任务爆栈了。
• 不要随手把任务栈分配得巨大，更合理的做法是按需估算：任务里的局部变量、函数调用深度、最大中断嵌套深度，然后留出20%到30%的冗余。

顺带一提，任务栈大小和中断嵌套深度有直接关系。中断用的是MSP没错，但如果在中断里调用了比较深的函数，MSP也可能溢出。很多“神秘重启”查到最后，其实是MSP的栈配置得太小，跟任务栈没关系。

6.3 中断里调调度函数：一个隐蔽的坑

有人图省事，直接在中断服务程序里调用任务切换函数，比如自定义的schedule，结果发现系统经常莫名其妙重启。原因很简单：中断里做切换，保存的是“中断现场”而不是“任务现场”，切换到别的任务再切回来时，中断栈的结构可能已经乱了。更严重的是，中断嵌套的压栈结构一旦被破坏，后果完全不可预测。

正确的做法是：中断里只做“改变任务状态”的工作，比如释放信号量、发消息、唤醒任务，真正的切换脏活交给PendSV。这也是为什么主流RTOS都要求“中断里只能调用ISR安全的API”——比如FreeRTOS里带FromISR后缀的那些函数。理解了PendSV的设计初衷，你就会明白这不是API设计得繁琐，而是架构上就必须这样。

6.4 优先级反转：选角逻辑的“潜规则”

最后再提一个面试高频、工程里也容易踩的坑：优先级反转。场景是这样的：高优先级任务A在等信号量，低优先级任务C正拿着信号量执行，中等优先级任务B在跑计算。A被唤醒后发现信号量被C占着，没法执行；而B又不让出CPU，于是高优先级的A反而被中等优先级的B“堵死”了。

解决思路常见有两种：

• 优先级继承：C持有信号量期间，临时把优先级提升到A的级别，执行完释放信号量再降回来。这样B没法插在C前面，A的等待时间就有了保障。
• 优先级天花板：给每个互斥量设定一个较高的优先级，谁拿到它，它的优先级就提到那个水平。

FreeRTOS的互斥量默认就带优先级继承机制，这也是为什么工程里建议用互斥量而不是单纯关中断来做临界区保护。这个例子说明，“任务调度”不只是“选角”那一刻的逻辑，它跟同步机制、中断设计、资源优先级都纠缠在一起。把基础链路掌握扎实，再往这些方向扩展，理解起来会快很多。

我个人在实际操作里的体会是：RTOS调度器并没有想象中那么神秘，它本质上是三块拼图——一张就绪表（数据结构）、一个选角函数（调度算法）、一段切换汇编（上下文切换机制）。把这三块拼图亲手拼一遍，再回头看FreeRTOS源码，你会发现它做的最多的其实是工程化的事情：内存管理、容错处理、统计、调试辅助、各种同步原语。但那个“调度内核”，就是这篇文章讲的部分，是所有RTOS的灵魂。

最后分享一个小技巧：想验证自己是不是真理解了，可以在调试器里单步跟踪一次任务切换，只在PendSV_Handler里设断点。看着R0-R11怎么进出栈、SP怎么变化、PC怎么跳到新任务的地址，这个过程比读十遍书都有用。等到你能把“从创建任务到第一次切换”的完整链条讲给别人听，基本就真正出师了。