企业官网建设流程全解析

1. 嵌入式任务调度到底在解决什么问题

1.1 从裸机大循环到多任务并发的必然演进

刚入行做单片机开发那会儿，我写的代码基本都是一个大循环包打天下。主函数里放一个while(1)，里面依次调用按键扫描、串口收发、数码管刷新、传感器读取，每个函数跑一遍，循环往复。这种结构在功能单一的场景下确实够用，代码直观，调试也简单，出了问题打断点一步步跟就行。

但项目一旦复杂起来，这套玩法很快就撑不住了。最典型的问题是实时性没法保证：如果某个函数执行时间过长，比如等待一个ADC转换完成或者处理一帧较长的串口数据，后面所有任务的响应都会被推迟。按键按下去要等几十毫秒才有反应，串口数据来了来不及接收直接丢包，这种问题在裸机架构下几乎无解，因为你没法在一个线性执行的流程里同时照顾到所有任务的时效要求。

于是很自然地就会想到：能不能让多个任务看起来“同时”在跑？每个任务只负责一件事，谁紧急谁先执行，不紧急的往后排。这就是任务调度要解决的核心问题——在单个CPU上，通过合理的切换策略，让多个任务分时复用处理器资源，同时保证关键任务的响应时间可控。嵌入式操作系统（RTOS）就是在这个需求下诞生的，而任务调度器则是整个RTOS最核心的部件，没有之一。

1.2 调度器的本质：在有限资源下做取舍

很多人刚接触RTOS的时候，会把调度器想得很神秘，觉得里面有什么高深算法。其实剥开来看，调度器干的事情非常朴素：维护一个就绪任务列表，每次需要切换的时候，从列表里挑一个最该跑的任务，把CPU交给它。就这么简单。

但“最该跑”这三个字大有文章。什么叫最该跑？是优先级最高的？是等了最久的？还是剩余时间片最少的？不同的判断标准就衍生出了不同的调度算法。而且嵌入式场景还有自己的特殊性：内存通常只有几十KB到几MB，CPU主频可能只有几十MHz，没有MMU（内存管理单元），中断响应要求通常在微秒级。这些约束决定了嵌入式调度器不能照搬桌面操作系统的做法，必须在功能和开销之间找到平衡点。

我见过不少初学者一上来就啃Linux的CFS调度器源码，结果被红黑树、虚拟运行时间这些概念绕得云里雾里，回头再看uC/OS-II的调度代码反而觉得太简单不像操作系统。其实这两者面向的场景完全不同，复杂度差异是合理的。理解这一点，后面的内容就好展开了。

2. 主流嵌入式调度方案的核心思路拆解

2.1 uC/OS的优先级抢占式调度：简单直接但有效

uC/OS（现在叫Micrium OS，但大家还是习惯叫uC/OS）在嵌入式圈子的地位不用多说，很多人的第一个RTOS就是它。它的调度器设计思路非常清晰：每个任务分配一个唯一的优先级，优先级数值越小优先级越高，调度器永远选择就绪态中优先级最高的任务运行。如果某个更高优先级的任务就绪了，立刻抢占当前任务，这就是“抢占式”的含义。

具体实现上，uC/OS用了一个非常巧妙的数据结构来加速查找。它维护一个OSRdyTbl[]数组作为就绪表，每个比特位对应一个优先级，1表示就绪，0表示未就绪。同时还有一个OSRdyGrp变量，每8个优先级为一组，只要组内有任务就绪，对应位就置1。查找最高优先级任务的时候，先查OSRdyGrp确定在哪一组，再查该组的OSRdyTbl确定具体是哪一位，两次查表就能定位，时间复杂度是O(1)。这个设计在uC/OS-II里最多支持64个优先级（8组×8位），到了uC/OS-III扩展到了256个，但核心思路没变。

这种调度方式的优点是确定性极强。任何时刻，最高优先级任务只要就绪就一定能拿到CPU，响应时间有严格上界。对于硬实时系统来说，这一点至关重要。但缺点也很明显：低优先级任务可能永远得不到执行机会，也就是所谓的“饥饿”问题。如果高优先级任务一直不阻塞，低优先级任务就永远在就绪表里躺着。实际项目中通常需要靠任务主动延时或等待信号量来让出CPU，这对开发者的设计能力有一定要求。

2.2 Linux CFS调度：追求公平的完全不同的哲学

如果说uC/OS的调度哲学是“强者通吃”，那Linux的CFS（Completely Fair Scheduler）就是“人人有份”。CFS从2.6.23内核开始成为默认调度器，它的核心思想是：给每个任务维护一个“虚拟运行时间”（vruntime），每次调度选择vruntime最小的任务运行。任务运行的时候vruntime会增长，但增长速度和任务的优先级（nice值）相关——优先级高的任务vruntime增长慢，优先级低的任务增长快。这样既保证了公平性，又体现了优先级差异。

CFS用红黑树来组织就绪任务，key就是vruntime。红黑树是一种自平衡二叉搜索树，查找、插入、删除的时间复杂度都是O(log n)。每次调度取红黑树最左边的节点，也就是vruntime最小的任务。任务运行一段时间后vruntime增加，如果不再是最小值，就被重新插入到树中合适的位置。这个“一段时间”就是调度周期，CFS会根据就绪任务数量动态调整，保证每个任务在周期内至少运行一次。

CFS的设计目标不是硬实时，而是吞吐量和公平性的平衡。它适合通用计算场景，比如服务器、桌面环境，这些场景下任务数量多、类型杂，很难为每个任务静态分配优先级。但在嵌入式实时场景下，CFS的公平性反而可能成为问题：一个低优先级的日志任务和一个高优先级的控制任务如果vruntime相近，日志任务可能会抢占控制任务的执行时间，这在硬实时系统里是不可接受的。所以嵌入式Linux通常需要配合RT补丁（PREEMPT_RT）或者使用双内核方案（如Xenomai）来满足实时性要求。

2.3 两种方案的适用场景对比

选哪个不是看哪个更“高级”，而是看场景需求。一个电机控制项目，任务数量少、实时性要求苛刻，uC/OS是更合适的选择。一个智能家居网关，需要同时跑网络协议栈、UI渲染、数据存储，任务数量多且优先级关系复杂，嵌入式Linux更合适。我个人的经验是：如果项目里有人提出“能不能跑个Python脚本”或者“需要接USB摄像头”，那基本就可以考虑上Linux了；如果项目要求“中断响应不超过5微秒”，那还是老老实实用RTOS。

3. 任务调度核心机制的深度解析

3.1 任务状态机：理解调度的基础

不管哪种RTOS，任务都不是一直处于可运行状态的。一个任务从创建到删除，会在几个状态之间迁移，理解这些状态是理解调度的前提。以uC/OS为例，任务主要有五种状态：休眠态（Dormant）、就绪态（Ready）、运行态（Running）、等待态（Waiting）、中断服务态（ISR）。

休眠态就是任务代码已经写好但还没被创建，或者已经被删除了。调用OSTaskCreate()之后任务进入就绪态，被放入就绪表。调度器选中它之后进入运行态，开始执行代码。如果运行过程中调用了OSTimeDly()或者等待信号量，就进入等待态，从就绪表中移除。等待的条件满足后（延时到期或信号量可用），重新回到就绪态。中断发生时，如果中断服务程序唤醒了某个更高优先级任务，中断返回时会触发调度，当前任务被换出，高优先级任务进入运行态。

这个状态机看起来简单，但实际调试中很多问题都出在状态迁移上。比如一个任务在等待信号量时被删除了，信号量却还被其他任务释放，就可能出现悬空指针。再比如中断服务程序里调用了会导致阻塞的API，任务状态机就乱了。这些坑后面会详细说。

3.2 上下文切换：调度器的“最后一公里”

调度器决定切换任务之后，真正完成切换动作的是上下文切换代码。所谓上下文，就是任务运行时CPU寄存器的值，包括程序计数器、堆栈指针、通用寄存器、状态寄存器等。切换的时候，先把当前任务的寄存器值保存到它的任务控制块（TCB）或堆栈中，再从下一个任务的TCB或堆栈中恢复寄存器值，最后跳转到新任务的执行点。

这个过程听起来简单，但有几个关键点容易出问题。第一是保存的完整性：有些寄存器在C函数调用规范里是“调用者保存”的，有些是“被调用者保存”的，上下文切换代码必须把所有可能被修改的寄存器都保存下来，漏一个就可能导致任务行为异常。第二是堆栈对齐：ARM Cortex-M系列要求堆栈8字节对齐，如果切换时堆栈指针没对齐，浮点运算或者某些库函数可能直接HardFault。第三是中断嵌套：如果在中断服务程序里触发调度，必须确保中断嵌套深度正确处理，否则可能破坏中断返回地址。

我实测过一个案例：在Cortex-M3上移植uC/OS，任务切换偶尔会跑飞。查了很久发现是PendSV异常处理程序里没有正确处理FPU寄存器的保存（虽然M3没有FPU，但代码里误用了M4的移植文件）。换成正确的移植文件后问题消失。这个教训说明上下文切换代码必须和具体内核架构严格匹配，不能想当然地复用。

3.3 调度时机：什么时候该切、什么时候不该切

调度器不是随时随地都在运行的，它只在特定时机被触发。这些时机主要包括：任务主动让出CPU（调用延时或等待API）、中断服务程序退出、任务优先级被动态修改、时间片用完（如果是时间片轮转调度）。

其中中断退出时的调度是最关键的。中断服务程序通常会释放信号量或发送消息，唤醒等待中的任务。中断处理完成后，系统需要判断是否有更高优先级任务就绪，如果有就触发切换。这个过程在uC/OS里叫“中断级任务切换”，在Linux里叫“中断返回调度”。实现方式通常是在中断退出前设置一个挂起标志，然后在中断返回指令执行前检查这个标志，如果需要切换就跳转到调度器。

这里有个常见的误区：很多初学者以为中断处理越短越好，于是在中断里只置个标志，把实际处理放到任务里做。这个思路本身没错，但如果标志置位后没有正确触发调度，高优先级任务可能要到下一个时间片才能运行，实时性就丢了。正确的做法是在中断退出前调用RTOS提供的调度触发API，比如uC/OS的OSIntExit()，它会自动判断是否需要切换。

4. 从零搭建一个可运行的任务调度框架

4.1 环境准备与基础数据结构定义

要真正理解调度器，光看代码不够，最好自己动手写一个简化版。下面我以Cortex-M内核为例，用C语言和少量汇编，搭建一个支持优先级抢占的迷你调度器。这个调度器不具备完整RTOS的功能，但足以展示核心原理。

首先定义任务控制块（TCB）和就绪表。TCB里至少要有堆栈指针、任务入口、优先级、状态这几个字段。就绪表用一个32位变量表示，每一位对应一个优先级，最多支持32个任务。

#define MAX_TASKS 32 #define STACK_SIZE 256 typedef enum { TASK_READY, TASK_RUNNING, TASK_BLOCKED } task_state_t; typedef struct { uint32_t *stack_ptr; // 保存任务堆栈指针 void (*entry)(void); // 任务入口函数 uint8_t priority; // 优先级，0最高 task_state_t state; // 任务状态 uint32_t stack[STACK_SIZE]; // 任务私有堆栈 } tcb_t; static tcb_t tasks[MAX_TASKS]; static uint32_t ready_bitmap = 0; // 就绪位图 static tcb_t *current_task = NULL;

这里ready_bitmap的每一位对应一个优先级，置1表示该优先级有任务就绪。查找最高优先级任务只需要找到最低位的1，可以用__builtin_ctz()（GCC内置函数）或者ARM的CLZ指令实现，效率很高。

4.2 任务创建与堆栈初始化

创建任务的时候，最关键的是初始化堆栈，让任务第一次被调度时能正确“返回”到入口函数。Cortex-M的堆栈在异常返回时会自动恢复8个寄存器（R0-R3、R12、LR、PC、xPSR），所以我们需要在堆栈里预先布置好这些值。

int task_create(void (*entry)(void), uint8_t priority) { if (priority >= MAX_TASKS) return -1; tcb_t *t = &tasks[priority]; t->entry = entry; t->priority = priority; t->state = TASK_READY; // 堆栈从高地址向低地址生长 uint32_t *sp = &t->stack[STACK_SIZE - 1]; // 布置异常返回时的寄存器值 *(--sp) = 0x01000000; // xPSR，Thumb位置1 *(--sp) = (uint32_t)entry; // PC，任务入口 *(--sp) = 0xFFFFFFFD; // LR，返回后使用PSP *(--sp) = 0; // R12 *(--sp) = 0; // R3 *(--sp) = 0; // R2 *(--sp) = 0; // R1 *(--sp) = 0; // R0 // 再保存R4-R11（手动保存的部分） for (int i = 0; i < 8; i++) { *(--sp) = 0; } t->stack_ptr = sp; ready_bitmap |= (1 << priority); return 0; }

这段代码里0xFFFFFFFD是Cortex-M的EXC_RETURN值，表示异常返回后使用进程堆栈指针（PSP），并且返回Thread模式。如果这个值设错了，任务第一次运行就会直接HardFault。我当初调试的时候就因为写成了0xFFFFFFF9（使用MSP）导致所有任务共用主堆栈，跑几个任务就栈溢出了。

4.3 调度器核心与PendSV切换实现

调度器本身很简单，就是找到最高优先级就绪任务，如果和当前任务不同就触发切换。触发切换的方式是设置PendSV异常挂起位，PendSV会在所有其他异常处理完成后执行，是专门为上下文切换设计的异常。

void schedule(void) { if (ready_bitmap == 0) return; // 没有就绪任务 uint8_t next_prio = __builtin_ctz(ready_bitmap); tcb_t *next = &tasks[next_prio]; if (next != current_task) { // 触发PendSV异常 *(volatile uint32_t *)0xE000ED04 = (1 << 28); } }

PendSV的处理程序需要用汇编写，因为要手动保存和恢复寄存器。核心逻辑是：先判断当前是否有运行中的任务，有就保存其堆栈指针；然后加载下一个任务的堆栈指针；最后恢复寄存器并异常返回。

PendSV_Handler: MRS R0, PSP ; 获取当前任务堆栈指针 CBZ R0, PendSV_NoSave ; 如果为0说明是第一次调度 STMDB R0!, {R4-R11} ; 保存R4-R11 LDR R1, =current_task ; 保存堆栈指针到TCB LDR R2, [R1] STR R0, [R2] PendSV_NoSave: LDR R0, =next_task ; 获取下一个任务TCB LDR R1, [R0] LDR R0, [R1] ; 加载堆栈指针 LDMIA R0!, {R4-R11} ; 恢复R4-R11 MSR PSP, R0 ; 更新PSP ORR LR, LR, #0x04 ; 确保异常返回使用PSP BX LR

这段汇编里STMDB R0!, {R4-R11}是递减堆栈并保存，LDMIA R0!, {R4-R11}是递增加载并恢复。注意Cortex-M的堆栈是满递减栈，所以用DB（Decrement Before）和IA（Increment After）配对。如果搞反了，保存和恢复的地址就对不上，任务切换后寄存器值全乱。

4.4 实测验证与性能评估

把上面的代码整合到一个工程里，创建三个任务：任务A每100ms翻转一个GPIO，任务B每200ms通过串口打印一条消息，任务C每500ms更新一次LCD显示。用逻辑分析仪抓GPIO波形，用串口助手看打印时间戳，实测下来任务切换的抖动在2微秒以内，完全满足一般工业控制的需求。

如果想进一步评估调度器的开销，可以在PendSV处理程序入口和出口各翻转一个IO，用示波器测量高电平持续时间。在STM32F103（72MHz）上，这个时间大约是1.2微秒，包括保存和恢复所有寄存器以及堆栈操作。这个开销在大多数场景下是可以接受的，但如果任务切换过于频繁（比如每毫秒切换几十次），累积开销就会影响CPU的有效利用率。这时候就需要考虑优化，比如减少不必要的切换、合并短任务、或者提高时间片长度。

5. 调度器实战中的典型问题与排查方法

5.1 优先级反转：现象、原因与解决方案

优先级反转是RTOS开发中最经典的坑，没有之一。现象是：一个高优先级任务突然被阻塞了很长时间，导致系统响应超时，但查代码又找不到明显的死循环或长延时。根本原因是有个低优先级任务持有高优先级任务需要的资源（比如互斥锁），而中间又有个中优先级任务一直在运行，导致低优先级任务拿不到CPU来释放资源。

举个例子：任务H（高优先级）等待互斥锁M，任务L（低优先级）持有M，任务M（中优先级）正在运行且不释放CPU。任务L因为优先级低于任务M，一直得不到调度，也就无法释放M，任务H就一直等。结果就是任务H被任务M间接阻塞了，而任务M的优先级其实比H低。

解决方案通常有两种：优先级继承和优先级天花板。优先级继承是指当低优先级任务持有高优先级任务需要的锁时，临时把低优先级任务的优先级提升到和高优先级任务相同，等释放锁后再恢复。uC/OS的互斥量（Mutex）就支持优先级继承，创建的时候把OSMutexPrioInherit选项打开即可。优先级天花板则是给每个互斥量设定一个天花板优先级，任何获取该锁的任务都会被提升到天花板优先级。两种方案各有适用场景，优先级继承更常用，但实现复杂度稍高。

5.2 栈溢出：最隐蔽的杀手

栈溢出是另一个高频问题，而且往往表现为随机崩溃，极难定位。每个任务都有自己独立的堆栈，如果任务里定义了大的局部数组、递归调用层数过深、或者中断处理使用了任务堆栈，都可能溢出。溢出后可能覆盖相邻任务的TCB或堆栈，导致完全不相干的代码出错。

排查栈溢出的方法有几个。最直接的是在任务堆栈的末尾填充特定模式（比如0xDEADBEEF），定期检查这些位置是否被改写。uC/OS提供了OSTaskStkChk()函数，可以统计任务堆栈的使用量，返回空闲栈空间大小。我通常会在调试阶段把栈检查放在空闲任务里，每隔一秒打印一次各任务的栈使用情况，一旦发现某个任务剩余栈空间低于20%就重点排查。

预防方面，首先要合理估算栈大小。一个经验公式是：栈大小 = 函数调用深度 × 每层栈帧大小 + 中断嵌套最大深度 × 中断栈帧大小 + 安全余量。Cortex-M的中断栈帧是32字节（8个寄存器×4字节），如果中断里还有函数调用，还要加上调用链的栈消耗。安全余量一般留30%到50%。其次要避免在任务里定义大数组，需要大缓冲区就用全局变量或动态分配。最后，如果编译器支持，开启栈保护选项（如GCC的-fstack-protector），能在溢出时触发异常而不是静默破坏内存。

5.3 调度延迟：从理论到实测的差距

理论分析调度延迟的时候，我们通常假设中断响应是即时的、调度器是O(1)的、上下文切换是固定开销的。但实测下来，从事件发生到高优先级任务开始执行，中间可能有好几微秒甚至几十微秒的延迟。这些延迟来自多个环节：中断响应延迟（CPU完成当前指令、保存现场）、中断处理时间（如果中断服务程序较长）、调度器执行时间、上下文切换时间。

要降低调度延迟，可以从几个方面入手。第一，缩短中断服务程序，只做最必要的操作，把耗时处理放到任务里。第二，提高中断优先级，确保关键中断能及时响应。第三，减少任务切换频率，避免不必要的调度。第四，如果CPU支持，使用尾链（Tail-Chaining）优化，连续的中断处理可以省去重复的现场保存恢复。第五，在Cortex-M上，把PendSV和SysTick的优先级设为最低，确保它们不会阻塞其他中断。

我实测过一个电机控制项目，最初调度延迟有15微秒，后来把电流环中断的优先级提到最高，把通信中断的优先级降低，延迟降到了3微秒以内。这个优化对电机控制的平滑性提升非常明显，低速运转时的转矩脉动小了很多。

5.4 常见问题速查表

6. 调度策略选型与进阶优化思路

6.1 根据项目需求选择调度算法

选调度算法不是选最先进的，而是选最合适的。我一般从几个维度来评估：任务数量、实时性要求、任务间依赖关系、开发团队经验。

任务数量少（10个以内）、实时性要求高（硬实时）、任务优先级关系明确的项目，优先级抢占式调度是最佳选择。uC/OS、FreeRTOS、RT-Thread都支持这种模式，代码成熟度高，社区资源丰富。任务数量多（几十个以上）、实时性要求相对宽松、任务类型多样的项目，可以考虑时间片轮转或者多级队列调度。Linux的CFS适合任务数量多且优先级动态变化的场景，但需要评估实时性是否满足。

如果项目里既有硬实时任务又有非实时任务，可以考虑混合方案：用RTOS跑硬实时任务，用Linux跑非实时任务，两者通过共享内存或消息队列通信。这种架构在工业网关、机器人控制器里很常见。选型的时候还要考虑团队的技术栈，如果团队都是单片机背景，强行上Linux可能反而增加项目风险。

6.2 调度器性能优化的几个实用技巧

第一个技巧是减少不必要的调度。每次调度都有开销，如果任务切换过于频繁，CPU大量时间花在保存恢复现场上。可以通过合并短任务、增大时间片、使用事件驱动代替轮询来降低切换频率。我见过一个项目，串口接收任务每收到一个字节就切换一次，波特率115200的时候每秒切换上万次，CPU利用率直接飙到80%。后来改成DMA接收加空闲中断，一次处理一帧数据，切换频率降到每秒几十次，CPU利用率降到5%以下。

第二个技巧是合理设置任务优先级。优先级分配要遵循“速率单调”原则：周期越短、实时性要求越高的任务，优先级越高。同时要避免优先级过于集中，留出足够的优先级空间给后续可能增加的任务。我通常会把优先级分成几个区间：0-10给硬实时任务，11-20给软实时任务，21-30给非实时任务，31给空闲任务。

第三个技巧是利用硬件特性。Cortex-M的PendSV异常专门用于上下文切换，不会阻塞其他中断。Cortex-M7等高端内核还有缓存和TCM（紧耦合内存），把调度器代码和任务堆栈放在TCM里可以显著降低访问延迟。如果CPU支持双堆栈（MSP和PSP），确保任务使用PSP，中断使用MSP，可以避免任务栈溢出影响中断处理。

6.3 从单核到多核：调度器的新挑战

现在多核MCU越来越常见，比如STM32H7的双核版本、ESP32的双核、树莓派RP2040的双核。多核调度比单核复杂得多，核心问题是如何在多个核之间分配任务，以及如何保证共享资源的一致性。

最简单的多核调度是AMP（非对称多处理）：每个核跑独立的RTOS实例，任务静态绑定到某个核，核间通过共享内存或消息队列通信。这种方式实现简单，但负载不均衡，一个核忙死另一个核闲死。更复杂的是SMP（对称多处理）：所有核共享一个就绪队列，调度器把任务分配到空闲的核上。SMP需要处理核间同步、缓存一致性、自旋锁等问题，实现难度大很多。

我个人的建议是：如果项目对算力要求不是特别苛刻，优先考虑AMP方案，把不同功能模块分配到不同核上，比如一个核跑控制算法，一个核跑通信协议栈。这样既能利用多核性能，又避免了SMP的复杂性。如果确实需要SMP，建议使用成熟的RTOS，比如FreeRTOS的SMP版本或者Zephyr，不要自己从头实现。

6.4 调试工具与手段推荐

调试调度问题，光靠打印和断点往往不够，需要一些专门的工具。硬件方面，逻辑分析仪和示波器是必备的，可以抓GPIO波形来观察任务执行时间和切换时机。如果MCU支持ETM（嵌入式跟踪宏单元）或SWO（单线输出），可以用Tracealyzer或者Percepio这样的工具做可视化跟踪，能看到每个任务的运行区间、切换原因、中断时序，非常直观。

软件方面，RTOS通常提供一些钩子函数（Hook），可以在任务切换、任务创建、栈溢出等事件发生时调用自定义代码。利用这些钩子可以记录调度历史，出问题的时候回溯。我习惯在任务切换钩子里记录时间戳和任务ID到一个环形缓冲区，系统崩溃后通过调试器读取缓冲区内容，就能还原崩溃前的调度序列。

如果条件允许，在开发阶段开启所有断言（Assert）和参数检查。uC/OS的OS_DEBUG_EN、FreeRTOS的configASSERT都能在参数非法时立即停机，避免问题扩散。这些检查在发布版本里可以关掉以节省开销，但调试阶段一定要开。

7. 一些踩坑后的个人体会

调度器这东西，看代码觉得简单，用起来才知道坑多。我最大的体会是：不要迷信“优先级越高越好”。很多初学者把所有任务都设成高优先级，结果就是高优先级任务互相抢占，系统反而更乱。优先级应该反映任务的实时性需求，而不是重要性。一个不紧急但重要的任务，优先级可以低一些，只要保证它最终能执行就行。

另一个体会是：调度器的行为高度依赖任务的设计。如果任务里到处是阻塞调用、长延时、忙等待，再好的调度器也救不了。我见过一个项目，任务里用while(!flag);等标志位，直接把CPU占满，其他任务全饿死。后来改成信号量等待，问题立刻解决。所以与其花时间调调度参数，不如先把任务设计好。

最后，不要过度设计。有些项目明明只有三五个任务，非要上复杂的调度算法，结果调试成本远超收益。简单场景用简单方案，把省下来的时间花在业务逻辑和测试上，项目成功率反而更高。调度器是工具，不是目的，能满足需求的就是好调度器。