1. 从点灯到多任务RTOS 的调度器到底在忙什么我先抛一个问题你已经跑通了裸机的点灯程序又试着在一个循环里轮询按键、刷新数码管可一旦某个函数卡住两毫秒其他活儿就全被堵死了。这时候你会想能不能让多个任务“同时”跑起来RTOS 给出的答案就是把 CPU 的时间切碎分给不同的任务而负责“切时间、分配 CPU”的这个核心部件就是调度器。标题里的关键词是“RTOS任务调度”说白了就是回答一个问题系统里同时躺着好几个任务CPU 只有一个到底让谁先上台跑这个选择和切换的过程就是调度。往深了挖它背后藏着一整套机制任务的优先级怎么排、就绪队列怎么维护、上下文怎么保存、切换的瞬间 CPU 的寄存器到底发生了什么变化。这篇内容是“从手搓操作系统开始”系列的第 6 篇前几篇我们分别写过了启动代码、时钟节拍、内存管理之类的模块这篇盯准的就是最核心的调度逻辑。这篇东西适合谁看我觉得是两类人。第一类已经在用 FreeRTOS 或 RT-Thread 做项目但遇到任务不切换、优先级不生效、死锁这类问题只能靠猜的开发者第二类是真的想搞明白“操作系统到底是怎么跑起来的”不满足于只会调用 API 的嵌入式学习者。读完之后你至少能画出自己手写 RTOS 的调度器框架也知道了任务切换时那句taskYIELD()背后到底执行了什么指令。先把这个概念捋清楚所谓任务调度本质上就是“在多个可运行的任务中按照某种规则挑一个出来把 CPU 交给它并且保证过一段时间之后还能完完整整地换回来”。这里面有三个关键词可运行、规则、完完整整换回来。可运行说明任务不是卡在延时或者等待信号量上规则说的是调度策略常见的有优先级抢占和时间片轮转完完整整换回来指的是上下文切换也就是寄存器和栈的保存与恢复。这三个点我会在这一篇里逐个拆开讲。2. 任务凭什么被“选中”任务控制块与就绪队列2.1 任务的身份证TCB 里都放了什么要让调度器认识一个任务光有函数指针是不够的。任务是一个“可以暂停、可以恢复、可以继续执行”的实体所以系统必须把它所有的状态都记下来。这个记录任务状态的结构体就叫任务控制块简称 TCBTask Control Block。我自己的第一版 TCB只有七个字段每个字段都有它的用处typedef struct tcb { uint32_t *stack_ptr; // 当前栈指针指向任务被切换出去时保存寄存器的位置 uint32_t *stack_base; // 栈底地址用于栈溢出检测 uint32_t stack_size; // 任务栈大小 uint8_t priority; // 任务优先级数值越小优先级越高 uint8_t state; // 任务状态就绪、运行、阻塞、挂起 volatile uint32_t tick_remaining; // 剩余阻塞时间延时用的 void (*entry)(void *arg); // 任务入口函数 void *arg; // 入口函数参数 } TCB;有人会问stack_ptr为什么要单独拿出来因为任务被切走的时候CPU 的寄存器是压在任务自己的栈里的栈指针指到哪儿决定了下次恢复时从哪儿弹寄存器。它也是判断任务有没有跑飞的重要参考——如果stack_ptr跑出了[stack_base - stack_size, stack_base]这个范围基本就是栈溢出了。我见过太多新手把任务栈开小了结果任务一跑复杂逻辑就内存踩踏现象诡异得没法查最终查来查去都是栈的问题。2.2 就绪队列的结构选择数组还是链表有了 TCB还得把所有“可运行”的任务组织起来让调度器能快速找到当前最应该跑的那个。这个组织方式就是就绪队列。设计上有两条路数组和链表。最简单的数组方案是按优先级建多个队列比如优先级 0~31就建 32 个链表头。每个任务按自己的优先级挂到对应的链表上调度的时候从最高优先级往下找找到第一个非空的链表取出链头任务执行。这种方案查起来非常快时间复杂度接近 O(1)是 FreeRTOS 采用的做法。还有一个更省内存的做法是单个链表按优先级排好序新任务就绪时插入到合适的位置。这种方案实现简单代码量少但插入和查找都要遍历链表任务一多效率就下来了。我自己手搓的时候第一版用的就是单链表因为够简单后来为了效率换成了多优先级链表再配合一个 32 位的就绪位图查找时间就稳定了。// 假设最大支持32个优先级 #define MAX_PRIORITY 32 // 每个优先级一个就绪链表头 static ListHead ready_list[MAX_PRIORITY]; // 就绪位图bit n 1 表示优先级为n的就绪链表非空 static volatile uint32_t ready_mask;查找最高优先级就绪任务就用一条指令加一次前导零计算// 找出当前最高优先级的索引假设优先级数值越小优先级越高 uint32_t find_highest_ready(void) { uint32_t mask ready_mask; // 使用前导零指令也可以写成 __builtin_clz(mask) return 31 - __builtin_clz(mask); }这段代码的效率非常关键。调度器是在中断里被调用的查找过程越快中断关闭的时间就越短系统的实时性就越好。实测下来位图法比遍历链表快了一个数量级这条优化路径值得投入。2.3 任务什么时候算“就绪”任务的状态不是一成不变的。我手写 RTOS 时任务状态机只实现了四个状态运行态RUNNING、就绪态READY、阻塞态BLOCKED和挂起态SUSPENDED。调度器只从就绪态里选人运行态本身就是就绪态的一个子集只不过它正占着 CPU。任务从阻塞态回到就绪态常见的有三种方式延时到了tick_remaining减到 0、等待的信号量被释放、等待的队列收到了消息。这些“唤醒”动作可以发生在另一个任务里也可以发生在中断里。无论发生在哪里最终都要做同一件事把 TCB 挂回就绪链表同时更新就绪位图。这里有一个很隐蔽的细节如果一个中断唤醒了高优先级任务RTOS 不会立刻切换过去而是把“需要切换”这个标记记下来等中断退出的时候再处理。这个机制在 Cortex-M 上就是 PendSV 的作用我后面专门讲。3. 调度策略的取舍优先级抢占和时间片轮转3.1 两种策略的适用场景对比调度策略是 RTOS 的“灵魂”它决定了任务的响应速度。常见的有两类优先级抢占式调度和时间片轮转调度。优先级抢占式意思是高优先级任务一旦就绪立刻打断当前正在运行的低优先级任务CPU 马上交给高优先级任务。这种策略保证了“重要的事先办”适合对实时性要求高的场景比如电机控制、传感器数据采集。它的代价是低优先级任务可能被饿死如果高优先级任务一直不阻塞低优先级永远轮不上跑。时间片轮转是让同一优先级的所有任务轮流使用 CPU每个任务跑一个固定长度的时间片时间片到了就换下一个。这种策略照顾了“公平”适合多个同等重要的任务比如 UI 刷新、按键扫描、LED 闪烁。它的代价是实时性差因为即使有高优先级任务就绪它也最多等一个时间片的时间。实际的产品里两者通常是结合着用不同优先级之间用抢占式同一优先级内部用时间片轮转。这种混合策略用一句话概括就是有高优先级来时立刻让位没有高优先级时兄弟几个轮流来。3.2 时间片多长才合适时间片的长短直接影响系统的响应速度。设得太短任务切换太频繁系统开销大CPU 大量时间花在存栈和弹栈上设得太长低优先级任务的响应延迟变大实时性变差。我一般建议时间片长度等于 1 到 10 个系统时钟节拍。时钟节拍通常配置为 1ms 或 10ms。如果以 1ms 为一个 tick时间片设为 5 个 tick意味着每个任务最多连续跑 5ms。这个值对于绝大多数嵌入式应用都是合理的。计算一下系统开销一次任务切换假设需要保存 16 个寄存器到栈里再加上从就绪链表里找新任务的时间大约需要 1~2 微秒以 Cortex-M4 主频 168MHz 估算。如果时间片设为 5ms切换开销占比不到 0.04%完全可以忽略。但如果把时间片设成 50 微秒切换开销占比就接近 4%这显然不划算。所以时间片别贪短够用就行。// 时间片到期的处理在SysTick中断里调用 void tick_handler(void) { // 遍历所有正在阻塞的任务递减剩余时间 for_each_blocked_task { tcb-tick_remaining--; if (tcb-tick_remaining 0) { set_ready(tcb); // 时间到转为就绪态 } } // 如果当前运行任务的时间片用完了并且同优先级还有其他就绪任务 if (current_task-time_slice_remaining 0) { if (other_ready_task_at_same_priority_exists()) { need_schedule 1; // 标记需要切换不立即切换 } else { current_task-time_slice_remaining DEFAULT_TIME_SLICE; } } else { current_task-time_slice_remaining--; } }看到没我在 tick 中断里没有直接调用任务切换而是置了一个need_schedule标志。为什么因为中断正在执行栈上压着一堆中断现场此时如果直接切换任务会把这个中断现场也压进任务的栈里导致一个任务莫名其妙多了一份“中断残留”。虽然这种设计在某些 RTOS 里是允许的但会带来不少坑。更稳妥的做法是等中断完全退出前在 PendSV 里做真正的切换。3.3 优先级反转一个经典的反面案例讲优先级抢占就得顺带提一个经典问题优先级反转。说的就是高优先级任务被低优先级任务阻塞中优先级任务趁机抢跑的情况。场景是这样的低优先级任务 A 拿到了一个互斥锁正在访问共享资源此时高优先级任务 C 也要访问这个资源发现锁被占只能阻塞等待。恰好中优先级任务 B 就绪了因为它优先级比 A 高就把 A 挂起了。结果就是C 在等 A而 A 被 B 挤压得根本跑不了C 被 B 间接挡住了明明优先级最高却迟迟执行不了。解决这个问题的常见手段是优先级继承当高优先级任务 C 等待锁时锁的持有者 A 暂时被提升到与 C 相同的优先级这样 B 就无法抢占 AA 尽快跑完释放锁C 得以继续执行。实现优先级继承的代码量不大但逻辑比较绕我建议对实时性要求高的项目一定要设计进去否则线上偶发延迟会让你排查到头秃。4. 切换的“惊险一跳”上下文切换到底发生了什么4.1 上下文是什么一文读懂寄存器现场任务说到底就是一段正在执行的代码。CPU 执行代码时依赖一组寄存器来记录“执行到哪儿了”“临时数据放在哪儿”。这套寄存器的内容就叫做 CPU 上下文Context。它至少包括程序计数器 PC下一条指令在哪、栈指针 SP当前栈顶在哪、通用寄存器 R0-R12临时变量、函数参数、状态寄存器 xPSR条件标志位。任务切换本质上就是“把当前任务的这套寄存器值保存起来把下一个任务的寄存器值恢复出来”。如果丢了一个寄存器任务恢复后要么变量算错要么整个逻辑跑飞。这也是为什么任务切换代码必须用汇编来写因为 C 语言会乱用寄存器没法精确控制上下文保存的范围。4.2 手写一个最小可用的上下文切换以 Cortex-M 为例我先给你看最核心的两段汇编。一段是“任务获取 CPU”时的弹栈恢复现场另一段是“任务交出 CPU”时的压栈保存现场。// 任务首次启动时从栈顶手动恢复现场跳到任务入口执行 __asm void prvStartFirstTask(void) { PRESERVE8 /* 栈指针指向任务栈中最后压入的初始上下文 */ ldr r0, current_tcb ldr r0, [r0] // r0 current_tcb-stack_ptr ldr sp, [r0] // sp 任务栈指针 /* 按入栈顺序弹栈依次恢复寄存器 */ pop {r4-r11} pop {r0-r3} pop {r12} pop {lr} pop {pc} // 程序跳转到任务入口 }// 任务切换保存当前任务现场加载新任务现场 __asm void vPortSVCHandler(void) { PRESERVE8 /* 1. 保存当前任务的上下文到它的栈里 */ mrs r0, msp // r0 当前栈指针 stmdb r0!, {r4-r11} // 手动保存 r4~r11 /* 把更新后的栈指针写回当前 TCB */ ldr r1, current_tcb ldr r1, [r1] str r0, [r1] // current_tcb-stack_ptr r0 /* 2. 切换到新任务这个动作由调度器决定 */ ldr r0, next_tcb ldr r0, [r0] ldr r1, [r0] // r1 next_tcb-stack_ptr ldr sp, r1 // 切换栈指针 /* 3. 从新任务的栈里恢复现场 */ ldmia sp!, {r4-r11} /* 剩下的 r0-r3, r12, lr, pc, xPSR 在 PendSV 退出时由硬件自动恢复 */ bx lr }这两段代码看起来短但每一行都有讲究。比如第一条mrs r0, msp为什么不用mov r0, sp因为在被中断打断的情况下处理器处于线程模式还是处理模式、用的是主栈还是进程栈都会影响sp的取值。用mrs r0, msp可以明确读出主栈指针。这些细节编译器不会帮你处理只能靠汇编手动保证。4.3 PendSV专门为任务切换设计的异常在 Cortex-M 上任务切换最优雅的做法是借助一个叫 PendSV可挂起的系统调用的异常。它的核心特点是它可以被高优先级的中断抢占而且在所有中断都处理完后才轮到它执行。我讲一下为什么需要它。假设任务 A 正在跑突然来了一个外部中断中断服务程序要唤醒任务 B。如果直接在中断里做上下文切换那么中断服务程序本身的现场包括返回地址、被中断的任务 A 的现场就会混进 B 的任务栈里。B 任务恢复时发现自己栈里莫名其妙多了一堆数据而且返回地址也乱了系统必挂。PendSV 的出现就是为了把任务切换的时机从“中断执行过程中”推迟到“所有中断退出之后”。具体流程是中断里如果发现需要切换任务就只做一件事——把 PendSV 的挂起位置 1。PendSV 的优先级配置成最低它不会打扰其他中断的执行。等当前中断和其他所有中断都执行完CPU 才会进入 PendSV此时栈上是干净的切换任务就是安全的。// 在中断里如果发现需要切换任务只需触发 PendSV void set_need_schedule(void) { // 在 Cortex-M 上往 ICSR 寄存器的 bit28 写 1 即可挂起 PendSV SCB-ICSR | SCB_ICSR_PENDSVSET_Msk; }配置 PendSV 优先级为最低的写法// 设置 PendSV 和 SysTick 的中断优先级 NVIC_SetPriority(PendSV_IRQn, 15); // 最低优先级 NVIC_SetPriority(SysTick_IRQn, 0); // 最高优先级SysTick 的优先级为什么要最高因为它负责生成系统心跳。如果心跳被其他中断堵住了那么所有依赖 tick 的功能延时、超时、时间片都会卡住。这个坑我很早之前踩过SysTick 优先级不应低于外部中断的优先级。5. 调度时机一共有几种任务切换的“触发点”5.1 主动让出从任务内部发起切换最简单的调度触发方式是任务自己主动放弃 CPU。这在 RTOS 里对应两个 API一个是task_yield()表示“我不跑了你们谁来”另一个是task_delay(ms)表示“我先睡一会儿到点叫我”。这两者虽然都触发调度但语义不太一样。task_yield()仅仅放弃了当前时间片但任务仍处于就绪态如果它优先级依然是就绪队列里最高的下一个时间片它还会被选中task_delay()则是主动进入阻塞态在延时结束前即使它是最高优先级也不会被调度到。实现task_delay()的核心就两步把任务状态改成阻塞态并从就绪链表里摘除把当前任务塞进一个按延时时间排序的阻塞队列里。这两步必须在临界区里完成否则会出现竞态条件——比如某个中断正好在同时把这个任务唤醒两边的逻辑就会打架。void task_delay(uint32_t ms) { uint32_t ticks ms / portTICK_PERIOD_MS; if (ticks 0) ticks 1; taskENTER_CRITICAL(); // 关中断保护临界区 // 从就绪队列移除当前任务 remove_from_ready(current_task); // 放入阻塞队列 current_task-state TASK_BLOCKED; current_task-tick_remaining ticks; insert_to_blocked_list(current_task, ticks); // 触发切换 set_need_schedule(); taskEXIT_CRITICAL(); // 开中断 }注意taskENTER_CRITICAL()和set_need_schedule()不能搞反顺序。如果先触发 PendSV还没进入临界区保护就绪队列中断一旦进来把队列改了调度器就可能选中一个已经不存在的任务内存直接崩掉。5.2 被“拽”去睡觉SysTick 时间片轮转除了任务主动让出还有一种被动切换就是时间片到期。SysTick 中断每来一次就把当前任务的时间片计数器减 1。减到 0 的时候如果同优先级还有其他就绪任务就触发 PendSV把 CPU 交给下一个任务。这个机制保证了一个任务写得再烂比如死循环死磕也无法永久垄断 CPU。只要有同等级的任务就绪它到点就会被换下去。这一点对调试特别有用——我在早期测试调度器时就是靠三个同优先级任务轮流翻转 LED 来验证切换是否正常的。5.3 中断“插队”之后由中断唤醒高优先级任务第三种调度触发点是外部中断里唤醒了高优先级任务。比如串口中断收到一个字节解析后发现这是一条控制指令需要立刻执行电机控制任务。此时串口中断服务函数里会做两件事给电机控制任务发一个信号量检查一下该任务的优先级是否高于当前任务。如果确实更高就置位 PendSV请求重新调度。这个机制看起来很自然但它有一个隐含要求中断不能调用普通任务上下文里的函数只能用“中断安全版本”的 API。这些 API 的内部操作必须是对中断安全的。我手写 RTOS 时给这些 API 都单独做了函数只有在中断里才会调。6. 常见问题与排查技巧实录调度器写完之后调试才是真正的修罗场。我自己在调的时候遇到过不少问题挑几个有代表性的记录一下。第一个问题任务跑着跑着就 HardFault。排查的思路先看栈。我遇到的情况是任务栈开得太小导致压栈时把内存踩到了相邻的 TCB。解决方法是给每个任务栈加上一个 magic number比如 0xDEADBEEF启动时检查 magic number 有没有被改写。如果被改写了立刻减小任务栈使用量或加大栈空间。第二个问题两个任务不切换了系统卡死在某个任务里。这种我碰到过好几次原因各不相同最常见的是忘记在延时或等待信号的语句里触发调度导致任务从不进入阻塞态。另外还有一种隐蔽情况某个外部中断的优先级高过了 SysTick结果这个中断的服务函数里又调用了等待类 API导致系统 tick 一直被卡住所有超时机制全部失效。查这类问题我的建议是先把一个 GPIO 翻转挂在 SysTick 里用示波器看心跳是否正常能快速定位是“调度器问题”还是“中断配置问题”。第三个问题是优先级反转现象。现象是某个任务偶尔延迟很大用示波器抓不到规律。我后来加了一个记录最大阻塞时间的变量每次任务被唤醒时计算出实际等待时间和期望等待时间的差距才定位到优先级反转。解决办法就是给互斥量加上优先级继承改完后再跑一周没有复现。我整理了一个速查表供你参考现象常见原因排查方法最终解决方案任务不切换未触发调度阻塞态未正确移除就绪链表检查是否调用了task_yield/task_delay打印任务状态在关键路径加入调度调用HardFault栈溢出切换时寄存器恢复不对用 magic number 检测栈越界检查汇编代码加大任务栈修正切换汇编延时不准SysTick 被高优先级中断阻塞示波器抓 SysTick 翻转脚降低外部中断优先级高优先级任务响应慢优先级反转记录最大阻塞时间实现优先级继承随机偶发死机中断里调用非中断安全 API代码审查改用中断安全版本 API在写这篇文章的过程中我最有体会的一点是调度器跑起来之后不要急着加功能先把三个任务、两个优先级、一个时间片的“最小系统”调稳。所有的异常、边界条件、极端情况在你确认基础切换正确之前都是干扰项。我自己的节奏是先让任务 A 和任务 B 互点 LED观察波形确认切换频率稳定然后再引入外部中断确认 PendSV 是在中断退出后才执行的最后再加信号量、互斥量这些同步机制。每一步都验证扎实后面出问题的概率会小很多。如果你是刚开始手写 RTOS我的建议是不要照抄 FreeRTOS 的完整代码先自己从 TCB 定义、就绪链表、SysTick 中断、PendSV 切换这四件事写起让系统转起来再优化。你会发现很多在文档上看得似懂非懂的概念写一遍就全通了。
RTOS任务调度器深度解析：优先级抢占与上下文切换
1. 从点灯到多任务RTOS 的调度器到底在忙什么我先抛一个问题你已经跑通了裸机的点灯程序又试着在一个循环里轮询按键、刷新数码管可一旦某个函数卡住两毫秒其他活儿就全被堵死了。这时候你会想能不能让多个任务“同时”跑起来RTOS 给出的答案就是把 CPU 的时间切碎分给不同的任务而负责“切时间、分配 CPU”的这个核心部件就是调度器。标题里的关键词是“RTOS任务调度”说白了就是回答一个问题系统里同时躺着好几个任务CPU 只有一个到底让谁先上台跑这个选择和切换的过程就是调度。往深了挖它背后藏着一整套机制任务的优先级怎么排、就绪队列怎么维护、上下文怎么保存、切换的瞬间 CPU 的寄存器到底发生了什么变化。这篇内容是“从手搓操作系统开始”系列的第 6 篇前几篇我们分别写过了启动代码、时钟节拍、内存管理之类的模块这篇盯准的就是最核心的调度逻辑。这篇东西适合谁看我觉得是两类人。第一类已经在用 FreeRTOS 或 RT-Thread 做项目但遇到任务不切换、优先级不生效、死锁这类问题只能靠猜的开发者第二类是真的想搞明白“操作系统到底是怎么跑起来的”不满足于只会调用 API 的嵌入式学习者。读完之后你至少能画出自己手写 RTOS 的调度器框架也知道了任务切换时那句taskYIELD()背后到底执行了什么指令。先把这个概念捋清楚所谓任务调度本质上就是“在多个可运行的任务中按照某种规则挑一个出来把 CPU 交给它并且保证过一段时间之后还能完完整整地换回来”。这里面有三个关键词可运行、规则、完完整整换回来。可运行说明任务不是卡在延时或者等待信号量上规则说的是调度策略常见的有优先级抢占和时间片轮转完完整整换回来指的是上下文切换也就是寄存器和栈的保存与恢复。这三个点我会在这一篇里逐个拆开讲。2. 任务凭什么被“选中”任务控制块与就绪队列2.1 任务的身份证TCB 里都放了什么要让调度器认识一个任务光有函数指针是不够的。任务是一个“可以暂停、可以恢复、可以继续执行”的实体所以系统必须把它所有的状态都记下来。这个记录任务状态的结构体就叫任务控制块简称 TCBTask Control Block。我自己的第一版 TCB只有七个字段每个字段都有它的用处typedef struct tcb { uint32_t *stack_ptr; // 当前栈指针指向任务被切换出去时保存寄存器的位置 uint32_t *stack_base; // 栈底地址用于栈溢出检测 uint32_t stack_size; // 任务栈大小 uint8_t priority; // 任务优先级数值越小优先级越高 uint8_t state; // 任务状态就绪、运行、阻塞、挂起 volatile uint32_t tick_remaining; // 剩余阻塞时间延时用的 void (*entry)(void *arg); // 任务入口函数 void *arg; // 入口函数参数 } TCB;有人会问stack_ptr为什么要单独拿出来因为任务被切走的时候CPU 的寄存器是压在任务自己的栈里的栈指针指到哪儿决定了下次恢复时从哪儿弹寄存器。它也是判断任务有没有跑飞的重要参考——如果stack_ptr跑出了[stack_base - stack_size, stack_base]这个范围基本就是栈溢出了。我见过太多新手把任务栈开小了结果任务一跑复杂逻辑就内存踩踏现象诡异得没法查最终查来查去都是栈的问题。2.2 就绪队列的结构选择数组还是链表有了 TCB还得把所有“可运行”的任务组织起来让调度器能快速找到当前最应该跑的那个。这个组织方式就是就绪队列。设计上有两条路数组和链表。最简单的数组方案是按优先级建多个队列比如优先级 0~31就建 32 个链表头。每个任务按自己的优先级挂到对应的链表上调度的时候从最高优先级往下找找到第一个非空的链表取出链头任务执行。这种方案查起来非常快时间复杂度接近 O(1)是 FreeRTOS 采用的做法。还有一个更省内存的做法是单个链表按优先级排好序新任务就绪时插入到合适的位置。这种方案实现简单代码量少但插入和查找都要遍历链表任务一多效率就下来了。我自己手搓的时候第一版用的就是单链表因为够简单后来为了效率换成了多优先级链表再配合一个 32 位的就绪位图查找时间就稳定了。// 假设最大支持32个优先级 #define MAX_PRIORITY 32 // 每个优先级一个就绪链表头 static ListHead ready_list[MAX_PRIORITY]; // 就绪位图bit n 1 表示优先级为n的就绪链表非空 static volatile uint32_t ready_mask;查找最高优先级就绪任务就用一条指令加一次前导零计算// 找出当前最高优先级的索引假设优先级数值越小优先级越高 uint32_t find_highest_ready(void) { uint32_t mask ready_mask; // 使用前导零指令也可以写成 __builtin_clz(mask) return 31 - __builtin_clz(mask); }这段代码的效率非常关键。调度器是在中断里被调用的查找过程越快中断关闭的时间就越短系统的实时性就越好。实测下来位图法比遍历链表快了一个数量级这条优化路径值得投入。2.3 任务什么时候算“就绪”任务的状态不是一成不变的。我手写 RTOS 时任务状态机只实现了四个状态运行态RUNNING、就绪态READY、阻塞态BLOCKED和挂起态SUSPENDED。调度器只从就绪态里选人运行态本身就是就绪态的一个子集只不过它正占着 CPU。任务从阻塞态回到就绪态常见的有三种方式延时到了tick_remaining减到 0、等待的信号量被释放、等待的队列收到了消息。这些“唤醒”动作可以发生在另一个任务里也可以发生在中断里。无论发生在哪里最终都要做同一件事把 TCB 挂回就绪链表同时更新就绪位图。这里有一个很隐蔽的细节如果一个中断唤醒了高优先级任务RTOS 不会立刻切换过去而是把“需要切换”这个标记记下来等中断退出的时候再处理。这个机制在 Cortex-M 上就是 PendSV 的作用我后面专门讲。3. 调度策略的取舍优先级抢占和时间片轮转3.1 两种策略的适用场景对比调度策略是 RTOS 的“灵魂”它决定了任务的响应速度。常见的有两类优先级抢占式调度和时间片轮转调度。优先级抢占式意思是高优先级任务一旦就绪立刻打断当前正在运行的低优先级任务CPU 马上交给高优先级任务。这种策略保证了“重要的事先办”适合对实时性要求高的场景比如电机控制、传感器数据采集。它的代价是低优先级任务可能被饿死如果高优先级任务一直不阻塞低优先级永远轮不上跑。时间片轮转是让同一优先级的所有任务轮流使用 CPU每个任务跑一个固定长度的时间片时间片到了就换下一个。这种策略照顾了“公平”适合多个同等重要的任务比如 UI 刷新、按键扫描、LED 闪烁。它的代价是实时性差因为即使有高优先级任务就绪它也最多等一个时间片的时间。实际的产品里两者通常是结合着用不同优先级之间用抢占式同一优先级内部用时间片轮转。这种混合策略用一句话概括就是有高优先级来时立刻让位没有高优先级时兄弟几个轮流来。3.2 时间片多长才合适时间片的长短直接影响系统的响应速度。设得太短任务切换太频繁系统开销大CPU 大量时间花在存栈和弹栈上设得太长低优先级任务的响应延迟变大实时性变差。我一般建议时间片长度等于 1 到 10 个系统时钟节拍。时钟节拍通常配置为 1ms 或 10ms。如果以 1ms 为一个 tick时间片设为 5 个 tick意味着每个任务最多连续跑 5ms。这个值对于绝大多数嵌入式应用都是合理的。计算一下系统开销一次任务切换假设需要保存 16 个寄存器到栈里再加上从就绪链表里找新任务的时间大约需要 1~2 微秒以 Cortex-M4 主频 168MHz 估算。如果时间片设为 5ms切换开销占比不到 0.04%完全可以忽略。但如果把时间片设成 50 微秒切换开销占比就接近 4%这显然不划算。所以时间片别贪短够用就行。// 时间片到期的处理在SysTick中断里调用 void tick_handler(void) { // 遍历所有正在阻塞的任务递减剩余时间 for_each_blocked_task { tcb-tick_remaining--; if (tcb-tick_remaining 0) { set_ready(tcb); // 时间到转为就绪态 } } // 如果当前运行任务的时间片用完了并且同优先级还有其他就绪任务 if (current_task-time_slice_remaining 0) { if (other_ready_task_at_same_priority_exists()) { need_schedule 1; // 标记需要切换不立即切换 } else { current_task-time_slice_remaining DEFAULT_TIME_SLICE; } } else { current_task-time_slice_remaining--; } }看到没我在 tick 中断里没有直接调用任务切换而是置了一个need_schedule标志。为什么因为中断正在执行栈上压着一堆中断现场此时如果直接切换任务会把这个中断现场也压进任务的栈里导致一个任务莫名其妙多了一份“中断残留”。虽然这种设计在某些 RTOS 里是允许的但会带来不少坑。更稳妥的做法是等中断完全退出前在 PendSV 里做真正的切换。3.3 优先级反转一个经典的反面案例讲优先级抢占就得顺带提一个经典问题优先级反转。说的就是高优先级任务被低优先级任务阻塞中优先级任务趁机抢跑的情况。场景是这样的低优先级任务 A 拿到了一个互斥锁正在访问共享资源此时高优先级任务 C 也要访问这个资源发现锁被占只能阻塞等待。恰好中优先级任务 B 就绪了因为它优先级比 A 高就把 A 挂起了。结果就是C 在等 A而 A 被 B 挤压得根本跑不了C 被 B 间接挡住了明明优先级最高却迟迟执行不了。解决这个问题的常见手段是优先级继承当高优先级任务 C 等待锁时锁的持有者 A 暂时被提升到与 C 相同的优先级这样 B 就无法抢占 AA 尽快跑完释放锁C 得以继续执行。实现优先级继承的代码量不大但逻辑比较绕我建议对实时性要求高的项目一定要设计进去否则线上偶发延迟会让你排查到头秃。4. 切换的“惊险一跳”上下文切换到底发生了什么4.1 上下文是什么一文读懂寄存器现场任务说到底就是一段正在执行的代码。CPU 执行代码时依赖一组寄存器来记录“执行到哪儿了”“临时数据放在哪儿”。这套寄存器的内容就叫做 CPU 上下文Context。它至少包括程序计数器 PC下一条指令在哪、栈指针 SP当前栈顶在哪、通用寄存器 R0-R12临时变量、函数参数、状态寄存器 xPSR条件标志位。任务切换本质上就是“把当前任务的这套寄存器值保存起来把下一个任务的寄存器值恢复出来”。如果丢了一个寄存器任务恢复后要么变量算错要么整个逻辑跑飞。这也是为什么任务切换代码必须用汇编来写因为 C 语言会乱用寄存器没法精确控制上下文保存的范围。4.2 手写一个最小可用的上下文切换以 Cortex-M 为例我先给你看最核心的两段汇编。一段是“任务获取 CPU”时的弹栈恢复现场另一段是“任务交出 CPU”时的压栈保存现场。// 任务首次启动时从栈顶手动恢复现场跳到任务入口执行 __asm void prvStartFirstTask(void) { PRESERVE8 /* 栈指针指向任务栈中最后压入的初始上下文 */ ldr r0, current_tcb ldr r0, [r0] // r0 current_tcb-stack_ptr ldr sp, [r0] // sp 任务栈指针 /* 按入栈顺序弹栈依次恢复寄存器 */ pop {r4-r11} pop {r0-r3} pop {r12} pop {lr} pop {pc} // 程序跳转到任务入口 }// 任务切换保存当前任务现场加载新任务现场 __asm void vPortSVCHandler(void) { PRESERVE8 /* 1. 保存当前任务的上下文到它的栈里 */ mrs r0, msp // r0 当前栈指针 stmdb r0!, {r4-r11} // 手动保存 r4~r11 /* 把更新后的栈指针写回当前 TCB */ ldr r1, current_tcb ldr r1, [r1] str r0, [r1] // current_tcb-stack_ptr r0 /* 2. 切换到新任务这个动作由调度器决定 */ ldr r0, next_tcb ldr r0, [r0] ldr r1, [r0] // r1 next_tcb-stack_ptr ldr sp, r1 // 切换栈指针 /* 3. 从新任务的栈里恢复现场 */ ldmia sp!, {r4-r11} /* 剩下的 r0-r3, r12, lr, pc, xPSR 在 PendSV 退出时由硬件自动恢复 */ bx lr }这两段代码看起来短但每一行都有讲究。比如第一条mrs r0, msp为什么不用mov r0, sp因为在被中断打断的情况下处理器处于线程模式还是处理模式、用的是主栈还是进程栈都会影响sp的取值。用mrs r0, msp可以明确读出主栈指针。这些细节编译器不会帮你处理只能靠汇编手动保证。4.3 PendSV专门为任务切换设计的异常在 Cortex-M 上任务切换最优雅的做法是借助一个叫 PendSV可挂起的系统调用的异常。它的核心特点是它可以被高优先级的中断抢占而且在所有中断都处理完后才轮到它执行。我讲一下为什么需要它。假设任务 A 正在跑突然来了一个外部中断中断服务程序要唤醒任务 B。如果直接在中断里做上下文切换那么中断服务程序本身的现场包括返回地址、被中断的任务 A 的现场就会混进 B 的任务栈里。B 任务恢复时发现自己栈里莫名其妙多了一堆数据而且返回地址也乱了系统必挂。PendSV 的出现就是为了把任务切换的时机从“中断执行过程中”推迟到“所有中断退出之后”。具体流程是中断里如果发现需要切换任务就只做一件事——把 PendSV 的挂起位置 1。PendSV 的优先级配置成最低它不会打扰其他中断的执行。等当前中断和其他所有中断都执行完CPU 才会进入 PendSV此时栈上是干净的切换任务就是安全的。// 在中断里如果发现需要切换任务只需触发 PendSV void set_need_schedule(void) { // 在 Cortex-M 上往 ICSR 寄存器的 bit28 写 1 即可挂起 PendSV SCB-ICSR | SCB_ICSR_PENDSVSET_Msk; }配置 PendSV 优先级为最低的写法// 设置 PendSV 和 SysTick 的中断优先级 NVIC_SetPriority(PendSV_IRQn, 15); // 最低优先级 NVIC_SetPriority(SysTick_IRQn, 0); // 最高优先级SysTick 的优先级为什么要最高因为它负责生成系统心跳。如果心跳被其他中断堵住了那么所有依赖 tick 的功能延时、超时、时间片都会卡住。这个坑我很早之前踩过SysTick 优先级不应低于外部中断的优先级。5. 调度时机一共有几种任务切换的“触发点”5.1 主动让出从任务内部发起切换最简单的调度触发方式是任务自己主动放弃 CPU。这在 RTOS 里对应两个 API一个是task_yield()表示“我不跑了你们谁来”另一个是task_delay(ms)表示“我先睡一会儿到点叫我”。这两者虽然都触发调度但语义不太一样。task_yield()仅仅放弃了当前时间片但任务仍处于就绪态如果它优先级依然是就绪队列里最高的下一个时间片它还会被选中task_delay()则是主动进入阻塞态在延时结束前即使它是最高优先级也不会被调度到。实现task_delay()的核心就两步把任务状态改成阻塞态并从就绪链表里摘除把当前任务塞进一个按延时时间排序的阻塞队列里。这两步必须在临界区里完成否则会出现竞态条件——比如某个中断正好在同时把这个任务唤醒两边的逻辑就会打架。void task_delay(uint32_t ms) { uint32_t ticks ms / portTICK_PERIOD_MS; if (ticks 0) ticks 1; taskENTER_CRITICAL(); // 关中断保护临界区 // 从就绪队列移除当前任务 remove_from_ready(current_task); // 放入阻塞队列 current_task-state TASK_BLOCKED; current_task-tick_remaining ticks; insert_to_blocked_list(current_task, ticks); // 触发切换 set_need_schedule(); taskEXIT_CRITICAL(); // 开中断 }注意taskENTER_CRITICAL()和set_need_schedule()不能搞反顺序。如果先触发 PendSV还没进入临界区保护就绪队列中断一旦进来把队列改了调度器就可能选中一个已经不存在的任务内存直接崩掉。5.2 被“拽”去睡觉SysTick 时间片轮转除了任务主动让出还有一种被动切换就是时间片到期。SysTick 中断每来一次就把当前任务的时间片计数器减 1。减到 0 的时候如果同优先级还有其他就绪任务就触发 PendSV把 CPU 交给下一个任务。这个机制保证了一个任务写得再烂比如死循环死磕也无法永久垄断 CPU。只要有同等级的任务就绪它到点就会被换下去。这一点对调试特别有用——我在早期测试调度器时就是靠三个同优先级任务轮流翻转 LED 来验证切换是否正常的。5.3 中断“插队”之后由中断唤醒高优先级任务第三种调度触发点是外部中断里唤醒了高优先级任务。比如串口中断收到一个字节解析后发现这是一条控制指令需要立刻执行电机控制任务。此时串口中断服务函数里会做两件事给电机控制任务发一个信号量检查一下该任务的优先级是否高于当前任务。如果确实更高就置位 PendSV请求重新调度。这个机制看起来很自然但它有一个隐含要求中断不能调用普通任务上下文里的函数只能用“中断安全版本”的 API。这些 API 的内部操作必须是对中断安全的。我手写 RTOS 时给这些 API 都单独做了函数只有在中断里才会调。6. 常见问题与排查技巧实录调度器写完之后调试才是真正的修罗场。我自己在调的时候遇到过不少问题挑几个有代表性的记录一下。第一个问题任务跑着跑着就 HardFault。排查的思路先看栈。我遇到的情况是任务栈开得太小导致压栈时把内存踩到了相邻的 TCB。解决方法是给每个任务栈加上一个 magic number比如 0xDEADBEEF启动时检查 magic number 有没有被改写。如果被改写了立刻减小任务栈使用量或加大栈空间。第二个问题两个任务不切换了系统卡死在某个任务里。这种我碰到过好几次原因各不相同最常见的是忘记在延时或等待信号的语句里触发调度导致任务从不进入阻塞态。另外还有一种隐蔽情况某个外部中断的优先级高过了 SysTick结果这个中断的服务函数里又调用了等待类 API导致系统 tick 一直被卡住所有超时机制全部失效。查这类问题我的建议是先把一个 GPIO 翻转挂在 SysTick 里用示波器看心跳是否正常能快速定位是“调度器问题”还是“中断配置问题”。第三个问题是优先级反转现象。现象是某个任务偶尔延迟很大用示波器抓不到规律。我后来加了一个记录最大阻塞时间的变量每次任务被唤醒时计算出实际等待时间和期望等待时间的差距才定位到优先级反转。解决办法就是给互斥量加上优先级继承改完后再跑一周没有复现。我整理了一个速查表供你参考现象常见原因排查方法最终解决方案任务不切换未触发调度阻塞态未正确移除就绪链表检查是否调用了task_yield/task_delay打印任务状态在关键路径加入调度调用HardFault栈溢出切换时寄存器恢复不对用 magic number 检测栈越界检查汇编代码加大任务栈修正切换汇编延时不准SysTick 被高优先级中断阻塞示波器抓 SysTick 翻转脚降低外部中断优先级高优先级任务响应慢优先级反转记录最大阻塞时间实现优先级继承随机偶发死机中断里调用非中断安全 API代码审查改用中断安全版本 API在写这篇文章的过程中我最有体会的一点是调度器跑起来之后不要急着加功能先把三个任务、两个优先级、一个时间片的“最小系统”调稳。所有的异常、边界条件、极端情况在你确认基础切换正确之前都是干扰项。我自己的节奏是先让任务 A 和任务 B 互点 LED观察波形确认切换频率稳定然后再引入外部中断确认 PendSV 是在中断退出后才执行的最后再加信号量、互斥量这些同步机制。每一步都验证扎实后面出问题的概率会小很多。如果你是刚开始手写 RTOS我的建议是不要照抄 FreeRTOS 的完整代码先自己从 TCB 定义、就绪链表、SysTick 中断、PendSV 切换这四件事写起让系统转起来再优化。你会发现很多在文档上看得似懂非懂的概念写一遍就全通了。
