1. 任务调度为什么是所有人在RT-Thread上踩的第一道门槛1.1 从裸机大循环切换到多任务后最先崩的往往是思维习惯我一直觉得评价一个人是不是真的入门了RT-Thread标准很简单让他描述一下某个线程在运行过程中被换下去的那一刻到底发生了什么。能说清楚说明他已经跨过去了说不清楚写再多业务代码也只是把裸机的大循环换了个名字。任务调度是RT-Thread的内核心脏它决定了谁能跑、跑多久、什么时候被打断。我见过太多人拿着例程把几个线程创建起来串口打印看着一切正常于是觉得自己会了等真正上项目多线程访问同一个环形缓冲区数据错乱、偶发死机、优先级高的线程长期抢不到CPU这时候才发现自己对调度的理解全是空的。这篇内容我想把它写成一份可复现的实战记录先讲清楚调度器在内核里处在什么位置、优先级位图是怎么做到常数时间查找的、线程控制块和就绪链表如何配合然后把栈大小估算、时间片换算这些容易糊弄过去但必须量化的问题算明白。中间会有一段完整的实验设计让你在自己板子上跑一遍就能看见抢占和时间片轮转的真实轨迹最后是我这几年排查调度问题时攒下来的一份速查资料包括栈溢出、优先级反转、临界区写错这些高频坑。无论你是刚从裸机转过来的新手还是已经写过几个项目但对调度机制仍然一知半解的开发者下面这些内容都能直接拿去用。我尽量不写那种“某某功能很强大”的空话能给出数字的地方就给数字能给出代码的地方就给代码。1.2 调度器站在系统的哪个位置管什么不管什么先把职责边界划清楚这决定了后面很多设计取舍的理解方式。RT-Thread是一个优先级抢占式的实时内核调度器本身只做三件事维护“就绪”状态的线程集合、在调度点选出当前应该运行的线程、触发上下文切换。它不管线程的创建销毁细节不管内存分配不管IPC对象内部的等待队列怎么排队那些是对象管理模块和IPC模块的事。调度器只接收一个结果某个线程从阻塞态变成就绪态了请把它的优先级位和就绪链表更新一下然后看要不要立刻抢当前线程的CPU。这个分工非常关键。因为很多人写代码时会把“线程唤醒了”和“线程开始跑了”混为一谈实际上rt_sem_release执行完毕只代表等待在这个信号量上的线程被移进了就绪表真正切换发生在函数返回前的调度点。理解这一点才能解释为什么在中断里释放信号量不会立即切换一般会推迟到中断退出时统一处理也才能解释为什么在临界区里释放信号量等待线程明明已经就绪了却还要等一会儿才跑起来。RT-Thread的调度点散布在几个固定位置线程主动让出rt_thread_yield、线程延时或挂起、线程等待IPC对象、信号量互斥量释放导致更高优先级线程就绪、中断服务程序退出时、以及调度器解锁的那一刻。所有这些位置最终都收敛到同一个函数rt_schedule。源码读到这里基本就通了剩下的都是它周边的配套中断嵌套计数rt_interrupt_nest、调度锁计数rt_scheduler_lock_nest、临界区计数rt_critical_level这几个变量是整个调度行为的开关后面我会专门拆。注意这里说的“调度点”是软件层面的可切换位置。硬件层面真正完成寄存器保存和恢复的是移植层的汇编比如Cortex-M上常用的PendSV异常。两者是“决定切”和“执行切”的关系混着看源码很容易看晕。2. 调度器内核设计就绪表、位图与O(1)查找2.1 优先级位图32个优先级如何被压进一个32位整数先说结论在默认配置下RT-Thread的调度查找是常数时间的与就绪线程数量无关靠的就是一张位图。原理不复杂但很多人只记住了“位图查找快”这个结论没真正算过。RT_THREAD_PRIORITY_MAX默认是32数值0是最高优先级31是最低。内核维护一个数组rt_thread_priority_table[]长度就是优先级数量每个元素是一条双向链表rt_list_t挂在这个优先级上所有就绪的线程。同时维护一个rt_thread_ready_priority_group通常是一个32位无符号整数第 n 位为1表示第 n 个优先级上有就绪线程。当某个线程就绪内核把链表插入对应优先级然后置位对应的bit线程被摘走且该优先级链表空了就清位。找最高优先级就变成了“找出这个32位数里最低的那个为1的位”。这就用到了__rt_ffs也就是find first set。GCC环境下直接映射到__builtin_ffs返回值从1开始计数减1就得到优先级号。汇编层面在Cortex-M3/M4上通常是一条CLZ指令count leading zeros配合一次减法几个周期就出来。这是这个设计最漂亮的地方不管你有3个还是30个就绪线程选下一个跑的对象永远是近似固定开销。/* 简化示意非内核原始实现 */ int __rt_ffs(int value) { if (value 0) return 0; return __builtin_ffs(value); } /* 调度核心取当前最高优先级就绪线程 */ rt_thread_t pick_next(void) { rt_ubase_t level __rt_ffs(rt_thread_ready_priority_group) - 1; rt_list_t *head rt_thread_priority_table[level]; return rt_list_entry(head-next, struct rt_thread, tlist); }那如果优先级数量超过32呢比如有些项目把RT_THREAD_PRIORITY_MAX配成256。这时候单靠一个32位整数装不下内核改用rt_thread_ready_table[32]也就是32组、每组32位再配一个rt_thread_ready_priority_group记录哪一组里有就绪线程。查找分两步先用组位图找第一个非空的组再在组内找第一个非空的位最终优先级 组号 × 32 组内偏移。仍然是常数时间只是常数变大了多一次查找。rt_ubase_t group __rt_ffs(rt_thread_ready_priority_group) - 1; rt_ubase_t bit __rt_ffs(rt_thread_ready_table[group]) - 1; rt_ubase_t prio (group 5) bit; /* group * 32 bit */这里有个我踩过的坑值得说优先级数量配大之后rt_thread_ready_table和就绪头数组的内存占用会线性增长在资源紧张的芯片上32个优先级每级一条链表头每个头两个指针8字节一共256字节换成256级就是2KB。如果你的RAM本来就只有20KB这么配纯属给自己找麻烦。我的经验是项目里实际用到的优先级超过8个基本说明优先级划分没想清楚数量不是问题层次才是。2.2 线程控制块与就绪链表的关系决定了插入删除的代价线程控制块struct rt_thread里跟调度直接相关的成员不多但每一个都不能忽视tlist是就绪链表节点current_priority是当前优先级注意它还可能是动态调整的init_priority是初始优先级stat是状态字还有stack_ptr指向当前栈顶sp保存上下文切换时的栈指针。把tlist单独拿出来做节点而不是把整个控制块当链表节点这个设计带来一个直接好处同一个线程既可以在就绪链表里也可以在IPC对象的等待链表里节点字段互不冲突不需要在状态切换时反复搬运数据。插入就绪链表时内核先看这个优先级对应的链表是不是空的如果是空的就要额外置位如果非空就直接尾插。这里“尾插”两个字很重要它意味着同优先级线程是按进入就绪状态的先后顺序排队的配合时间片机制就能实现同优先级轮转。如果你的优先级表配得合理绝大多数线程都有自己独立的优先级那么每个链表里通常只有一个节点插入删除几乎就是几条指针赋值。状态字stat是排查问题的第一现场。它是由几个位组合成的就绪、运行、挂起、关闭等基础状态再加上“在挂起列表上”的标记。用MSH的list_thread命令看到的ready、running、suspend、close就是从这里翻译过来的。看到某个线程长期是suspend而不是ready直接去查它等的是什么对象看到状态在ready和running之间反复横跳但业务没推进那就是被更高优先级线程压制了问题出在优先级分配而不是调度器本身。提示调试时不要只看线程状态还要看线程的error字段和栈的最大使用量。list_thread输出里那两列数值一个是栈的总大小一个是历史峰值使用量。峰值逼近总量的时候不用怀疑你离一次HardFault只差一个中断嵌套。2.3 抢占式、时间片轮转、非抢占三种策略到底该用哪个RT-Thread的行为由RT_THREAD_PRIORITY_MAX加上时间片开关共同决定实际表现出来的有三种典型形态选错会直接影响系统的实时性和响应抖动。第一种是纯优先级抢占。高优先级线程一旦就绪立刻打断当前正在运行的低优先级线程。这是实时系统的核心能力也是绝大多数控制类项目需要的。它的代价是如果高优先级线程设计不当比如无限循环不让出低优先级线程会被永久饿死。我见过一个项目串口接收线程优先级配成最高而它在等待数据时用的是忙等while(!flag)结果整机只跑这一个线程其余全挂起。调度器没做错任何事是人把它用成了死循环。第二种是同优先级时间片轮转。需要打开时间片功能并给线程指定tick值。同优先级的多个线程依次运行各自的时间片用完被移到链表尾部。适合那种“逻辑上对等、没有严格先后关系”的线程比如多个上报通道、多个界面刷新任务。但必须清楚时间片轮转是“近似公平”不是实时保证用它做硬实时同步一定会出问题。第三种是关闭抢占RT_THREAD_PRIORITY_MAX相关的调度配置或临界区导致的软行为。实际项目里更常见的做法不是关全局抢占而是在小段代码用rt_enter_critical制造一个不允许调度的窗口。这种局部手段比全局关抢占安全得多因为它影响范围可控退出后调度器会立即补一次调度。策略开启条件典型场景主要风险优先级抢占默认开启控制回路、中断响应后处理高优先级线程忙等导致低优先级饥饿同优先级时间片需启用时间片并设置tick多个对等数据上报、多通道采样误当实时同步使用抖动不可控局部禁止调度rt_enter_critical包裹几行代码的共享数据更新包裹范围过大破坏响应性我的选择习惯是业务线程全部给不同优先级尽量不用时间片如果确实出现两个完全对等的任务我宁可把它们合成一个线程用状态机跑也不轻易开时间片。原因很实在时间片带来的调度次数增加会让日志变得极难读出问题时你要在一堆交替打印里找因果成本远高于收益。3. 关键参数与机制栈、时间片、临界区3.1 线程栈大小到底怎么算别再拍脑袋写1024栈溢出是RT-Thread新手最常见的事故而源头几乎都是“随手填个数”。这里给一套可操作的估算方法不是精确值但能把你从“1024万能论”里救出来。计算分四块加上余量。第一块是硬件上下文Cortex-M内核进入异常时会自动压栈R0-R3、R12、LR、PC、xPSR共8个寄存器32字节。第二块是软件上下文切换时手动保存R4-R11又是32字节。如果芯片带FPU且线程浮点运算中发生切换还要额外保存S0-S15和FPSCR约72字节具体看移植层实现。这64到136字节是任何线程都逃不掉的固定开销。第三块是函数调用链的栈帧。这个要看你这段线程里最深的调用路径每层函数调用会压入局部变量、返回地址、可能的寄存器保存。经验值不含浮点和递归的常规业务代码单层10到30字节带浮点运算的一层可能到60到100字节。第四块是局部大数组和printf系列。printf这类函数在嵌入式上是栈大户尤其是格式化浮点占几百字节不奇怪。/* 一个容易低估栈的写法 */ void thread_entry(void *param) { char buf[128]; /* 128 */ double val 3.14159; /* 浮点上下文 局部 */ rt_kprintf(val%f\n, val); /* printf 内部栈消耗视C库而定 */ ... }我一般这么估默认起步给 1024 字节不含堆的情况下线程控制块单独算跑起来后通过list_thread观察峰值再乘以1.5到2作为最终值。开浮点或者用printf的线程起步直接 2048。别怕浪费一个线程多给512字节十个线程也就5KB一次栈溢出让整机跑飞排查成本是这个的几十倍。还有个容易忽略的点栈的对齐。ARM架构要求8字节对齐特别是涉及双精度浮点或长整型时。自己用数组做静态线程栈时务必用编译器的对齐属性修饰否则偶发的非对齐访问异常会让人怀疑人生。ALIGN(8) rt_uint8_t thread_stack[2048];3.2 时间片换算一个tick到底是多久RT_TICK_PER_SECOND决定了系统的心跳频率默认1000也就是一个tick对应1毫秒。这个值不是随便定的它直接决定了所有基于tick的延时和超时的最小分辨率。你写rt_thread_mdelay(1)在1000Hz配置下是1毫秒在100Hz配置下就成了10毫秒而且实际延时可能是一个tick到两个tick之间的任意值。换算公式很简单一个tick的时长 1000 /RT_TICK_PER_SECOND毫秒。线程的时间片也以tick为单位如果你的线程时间片设为5在1000Hz下就是5毫秒在100Hz下是50毫秒。这里有个连锁反应时间片变长同优先级轮转的粒度变粗每个线程连续占用CPU的时间变长但总切换次数下降、开销变小。所以时间片的取值本质是“响应粒度”与“调度开销”之间的权衡。我做过的实测对比同优先级三个线程各跑一个简单的计数循环时间片从1改到10切换次数下降约一个数量级但单个线程的连续执行时间明显变长。对于需要快速响应的多人机交互场景时间片给1到2比较合适对于后台批量处理类的对等任务5到10完全够用。另外提醒一点rt_thread_delay和rt_thread_mdelay在内部都按tick换算传入0的意义在不同版本里可能是“不延时直接返回”也可能是“让出一次”写代码时不要依赖这个边界行为想主动让出就用rt_thread_yield语义明确。延时精度方面由于tick中断是周期性的实际唤醒时刻会有一个tick以内的误差需要更高精度的场合得靠硬件定时器而不是靠调度器。3.3 关中断、调度锁、临界区这三个真的不是一回事这三个概念混用会导致非常隐蔽的问题我把它们的行为列清楚。关中断rt_hw_interrupt_disable/rt_hw_interrupt_enable是硬件层面的恢复的是进入前的PRIMASK状态可以嵌套使用但必须成对。关中断期间不响应任何中断包括tick所以延时不准、通信丢包都可能由此产生必须限制在极短代码段内。调度锁rt_enter_critical/rt_exit_critical只禁止线程切换中断照常响应中断服务程序照常执行。它维护rt_scheduler_lock_nest计数嵌套深度大于0时rt_schedule直接返回。适合保护“不希望被其他线程打断但允许中断进来”的共享数据。临界区在RT-Thread语境里常常就是指这两者的统称但代码里对应的是不同API别搞混。机制影响中断影响线程切换可嵌套典型用途关中断是是是按状态恢复操作硬件寄存器、极短原子序列调度锁否是是计数保护多线程共享的结构体字段信号量/互斥量否否可能触发调度视对象而定跨线程的资源互斥可阻塞等待一个真实案例某项目在调度锁保护的代码段里调用了rt_sem_take并设置了等待超时。因为调度锁生效等待中的线程无法切换出去rt_sem_take立即返回超时逻辑表现为“信号量永远取不到”。这不是内核的bug是在不该阻塞的地方阻塞了。记住一条临界区里只做内存操作不做任何可能引起阻塞的调用。4. 实操跑通一次能看见抢占和时间片的调度实验4.1 静态创建与动态创建的选择依据先解决创建方式。静态创建用rt_thread_init线程控制块和栈都由你自己提供内存可以是全局数组或内存池分配动态创建用rt_thread_create内核从堆上分配控制块和栈用完rt_thread_delete释放。两者的调度行为完全一致区别只在内存来源和生命周期管理。/* 静态创建 */ ALIGN(8) static rt_uint8_t stack_a[1024]; static struct rt_thread thread_a; rt_err_t init_a(void) { return rt_thread_init(thread_a, thA, entry_a, RT_NULL, stack_a, sizeof(stack_a), 20, 10); } /* 动态创建 */ rt_thread_t tid rt_thread_create(thB, entry_b, RT_NULL, 1024, 20, 10); if (tid ! RT_NULL) { rt_thread_startup(tid); }我的选型原则很干脆功能固定、数量确定的线程一律静态创建启动阶段一次性初始化完成运行时不再有内存分配堆碎片和分配失败的风险直接归零只有在“线程数量随外部事件动态变化”的场景才用动态创建比如每个连接一个处理线程这种设计其实这种设计本身我也建议改成线程池。顺便说官方例程多数用动态创建导致很多人以为那是标准写法。在资源受限的板子上启动阶段一堆rt_thread_create会让堆压力集中在初始化期如果堆配置偏小失败发生在第二第三个线程上表现为“某些功能没跑起来”排查起来莫名其妙。静态创建不会有这个问题失败会直接编译或者初始化返回错误码一目了然。4.2 一套能在串口上直接看到抢占过程的实验设计光看代码看不出调度得设计能观察的实验。我的做法是用三个线程构造两种关系两个同优先级线程观察时间片轮转一个更高优先级线程观察抢占。参数这么定RT_TICK_PER_SECOND配1000。线程 A 优先级15时间片10线程 B 优先级15时间片10线程 C 优先级8不做延时只在被唤醒时打印。主线程优先级10负责周期性唤醒C。static void entry_a(void *p) { while (1) { rt_kprintf([A] tick%d\n, rt_tick_get()); rt_thread_mdelay(50); } } static void entry_b(void *p) { while (1) { rt_kprintf([B] tick%d\n, rt_tick_get()); rt_thread_mdelay(50); } } static void entry_c(void *p) { while (1) { rt_sem_take(sem_c, RT_WAITING_FOREVER); rt_kprintf([C] preempt, tick%d\n, rt_tick_get()); /* 故意做一段耗时的打印观察抢占效果 */ } }预期现象A和B因为同优先级各自延时50ms后进入就绪谁先就绪谁先跑打印交替出现C被释放时因为优先级8高于A/B的15会立刻打断正在运行的A或B日志里[C]会插在[A]的两次打印中间。如果观察不到插入先确认信号量释放后是否发生了调度rt_sem_release内部会检查再确认C线程确实处于挂起等待态而不是还没启动。这个实验的价值在于把三个概念同时呈现同优先级轮转、延时导致的挂起与唤醒、高优先级抢占。跑通它比读十遍源码管用。延伸一步把C的优先级改成15和A/B相同再观察一次。你会发现[C]不再立即插队而是要等同优先级轮转到它这正好验证了“抢占只在优先级更高时发生”这条规则。4.3 用列表命令和钩子把调度轨迹记录下来串口打印只是最粗的手段我更推荐用系统的线程列表命令配合调度钩子。MSH下执行list_thread部分版本是ps输出里能看到每个线程的优先级、状态、剩余时间片、栈使用峰值、错误码。定时打印一次这个列表调度行为基本就浮出水面了。更细的可以用调度器钩子。rt_scheduler_sethook注册的函数在每次任务切换时被调用参数是即将切换出的线程和即将切入的线程。在这个钩子里记录tick和两个线程的名字就得到了一条完整的切换时间线。注意钩子运行在调度器的关键路径上里面只能做极轻量的操作串口打印都嫌重最好是往一个预分配的环形缓冲区里写记录事后统一输出。static void sched_hook(struct rt_thread *from, struct rt_thread *to) { /* 只做轻量记录不要打印 */ log_push(rt_tick_get(), from ? from-name : none, to-name); }分析这条时间线时我关注三个指标单位时间内的切换次数、某线程从就绪到首次运行的最大延迟、以及同优先级线程之间的运行时长是否大致等于设定时间片。第三个指标如果明显偏离往往说明有更高优先级线程在频繁抢占或者时间片配置没生效。提示钩子里千万别调用任何会触发调度的API包括打印。一旦在切换过程中再次触发切换行为是未定义的。这个坑我吃过一次现象是系统偶发死机最后定位到钩子里的rt_kprintf。5. 常见故障排查从现象倒推调度问题5.1 一份可以直接对着查的异常速查表调度相关问题有个特点现象千奇百怪根因往往就那么几类。我把这几年遇到的整理成表按现象查比按理论推快得多。现象高概率原因排查动作某线程完全不运行优先级被长期抢占、线程未启动、卡在阻塞调用查list_thread状态确认是否ready查是否有更高优先级忙等线程系统随机死机复位栈溢出、中断中调用阻塞API、钩子里触发调度看栈峰值是否贴近上限检查中断服务程序里的调用打印顺序错乱、数据被截断多线程共用同一串口未加保护加互斥量或用统一日志线程同优先级线程一个跑一个饿时间片未启用或配置为0确认时间片配置宏与线程tick参数延时明显不准tick中断被长时间关闭、优先级配置过低检查关中断代码段长度信号量在临界区内取不到调度锁生效导致无法阻塞等待移出临界区或改用不阻塞方式表格里最容易被忽略的是第二条。中断服务程序里调用rt_thread_mdelay、rt_sem_take带超时这类阻塞API编译器不会报错运行起来可能几天才出一次问题。规矩很简单中断里只做标记、放队列、释放信号量任何“可能让当前执行流停下来”的调用一律不碰。5.2 栈溢出和异常复位怎么在几分钟内定位到栈溢出的经典表现是某个变量莫名其妙被改、函数返回到非法地址、进入异常处理不返回。如果芯片有MPU或栈保护能直接捕获没有的话就得靠事后分析。第一步看list_thread里的栈使用峰值。所有线程峰值都在合理范围唯独某个线程接近或超过总量基本就锁定了。第二步把那个线程的栈临时放大一倍如果问题消失确认是溢出再回头分析是哪个函数吃栈太多。第三步如果放大后问题依旧那可能不是栈的问题去看是不是数组越界写坏了相邻的内存。还有个技巧在线程栈的末尾栈生长方向的最深处预先填充一段固定魔数比如 0xDEADBEEF运行一段时间后检查这段魔数是否被改写。被改写说明栈已经踩到底了。这个手段比看峰值更早报警因为峰值统计可能因为采样点问题漏掉瞬间的深调用。/* 静态栈末尾预置魔数运行中周期性检查 */ #define STACK_MAGIC 0xDEADBEEF ALIGN(8) static rt_uint8_t stack_a[1024]; static void stack_guard_init(void) { *(rt_uint32_t *)stack_a STACK_MAGIC; } static int stack_overflowed(void) { return *(rt_uint32_t *)stack_a ! STACK_MAGIC; }要注意栈的生长方向和填充位置Cortex-M的栈是向低地址生长的所以魔数应该放在数组起始的低地址处。不同移植层细节可能不同动手前先确认一下。5.3 优先级反转为什么加了互斥量系统反而更慢优先级反转是个老话题但在实际项目里依然高发因为它不报错只是表现为“系统卡顿”“响应变慢”很容易被归因到芯片性能不足。典型场景是这样低优先级线程L持有互斥量正在操作共享数据中优先级线程M就绪并抢占L开始长时间运行此时高优先级线程H需要同一把锁只能等L释放而L又拿不到CPU因为M在跑。结果H被M间接阻塞实时性彻底失效。注意这里的关键是M和这把锁毫无关系纯属路过把L压住了。正确做法是使用支持优先级继承的互斥量RT-Thread的rt_mutex就具备这个能力。当H等待被L持有的锁时L的优先级临时提升到H的水平保证它能尽快执行完退出临界区释放后优先级恢复。用二值信号量做互斥就没有这个保护这也是我坚持“资源互斥用互斥量、事件通知用信号量”的原因。static rt_mutex_t lock; void shared_update(void) { rt_mutex_take(lock, RT_WAITING_FOREVER); /* 只放必要的数据操作别在这里做耗时计算 */ rt_mutex_release(lock); }即便有优先级继承也要尽量缩短持锁时间。我见过在互斥量保护下做Flash擦写的一次几百毫秒任何等待这把锁的线程全被拖住。耗时的操作应该拆出去锁内只做数据交换。另外互斥量不能在中端服务程序里使用中断没有线程上下文谈不上优先级继承这条限制必须记住。6. 优先级分配和调度的几条实战心得优先级怎么分文档不会告诉你因为跟业务强相关。但我有一套一直在用的规则落地效果不错。先把线程按“时间约束的严格程度”排序而不是按“重要性”。中断后处理、串口协议解析这类有硬时限的放最高档比如0到4控制回路、采样任务放中间档5到12上报、日志、界面刷新放低档13到20空闲和清理类放最低。同一档里如果出现多个线程先自问能不能合并多数情况下答案是能。给每个线程配优先级时我心里有张表写代码前先填好避免边写边改导致优先级乱套。线程类型建议优先级区间是否用时间片备注中断后处理、协议解析0-4否必须短小绝不阻塞实时控制、采样5-12否周期固定执行时间可控业务逻辑、状态机13-20视情况尽量合并减少数量上报、日志、界面21-28可用允许被延迟空闲清理最低否放在空闲钩子里还有个心得是关于rt_thread_mdelay的使用。很多新手把它当sleep用写while(1){ 干活; mdelay(10); }这种“轮询加延时”的模式在实时系统里是浪费因为延时期间线程虽然让出了CPU但醒来第一件事是检查有没有活干没有就继续睡。更好的做法是让线程阻塞在信号量或消息队列上有事件才唤醒。这不只是效率问题也直接影响调度的可预测性——阻塞等待的线程完全不出现在就绪表里对调度器是零负担。最后说一个我反复验证过的经验调度的很多“奇怪现象”最后都不是调度器的问题而是共享数据没保护、阻塞调用放错位置、栈给得太小这三件事。出问题时先按这三条过一遍能省掉大量翻源码的时间。真要去读rt_schedule的实现建议从rt_thread_resume和rt_thread_suspend这两个函数入手它们分别对应线程进出就绪表的两条路径把这两条路径上的链表操作和位图置位看清楚整个调度器的骨架也就清楚了。