📚 课程目录第4章任务管理

4、任务管理：任务创建与删除、任务状态机、优先级与调度算法（优先级抢占、时间片轮转）、任务同步与通信

在航天飞行器的嵌入式软件系统中，VxWorks 作为实时操作系统（RTOS）承担着姿态控制、轨道计算、遥测采集、指令执行等关键功能。任务（Task）是 VxWorks 中独立调度的最小执行单元，任务管理的质量直接决定了系统能否在严格的时序约束下正确响应外部事件。本章围绕任务的全生命周期展开，深入解析任务创建与删除的底层机制、任务状态机的迁移条件、优先级抢占与时间片轮转的调度策略，以及任务间同步与通信的典型手段，并结合航天工程中的实际约束给出可落地的设计建议。

上图从宏观视角展示了任务管理的四大核心模块及其与内核调度器的关系。在航天软件中，任务并非孤立存在，它们通过调度器共享 CPU 资源，通过同步与通信机制协作完成复杂功能。下面逐一深入剖析每个模块的工程实现细节。

4.1 任务创建与删除：从静态配置到动态管理

4.1.1 核心原理

VxWorks 中任务由任务控制块（TCB）唯一标识，TCB 保存了任务的上下文环境，包括寄存器组、栈指针、调度优先级、状态、入口函数指针等。任务创建的本质是分配并初始化 TCB 和任务栈，然后将任务插入就绪队列。VxWorks 提供两种创建方式：taskSpawn() 用于动态创建，sp() 是其简化封装；而静态任务则通过 taskInit() 在系统启动阶段预分配资源。

任务删除则相反，taskDelete() 会释放 TCB 和栈内存，并将任务从所有内核队列中移除。需要特别注意的是，任务删除是异步操作，被删除任务可能正在持有信号量或处于临界区，直接删除会导致资源泄漏或系统死锁。航天软件中通常采用“请求删除”模式：任务在安全点自行检查删除标志并退出。

4.1.2 操作流程与参数配置

任务创建的关键参数包括优先级（0-255，0 为最高）、栈大小、入口函数及参数。在航天应用中，栈大小必须经过静态分析确定，通常取最大调用深度的 1.5~2 倍余量。以下是一个典型的任务创建代码示例：

/* 姿态控制任务，优先级 50，栈 16KB */
int taskId = taskSpawn("AttCtrl", 50, VX_FP_TASK, 16384,
                       (FUNCPTR)AttCtrlLoop, 0,0,0,0,0,0,0,0,0,0);
if (taskId == ERROR) {
    logMsg("AttCtrl task spawn failed, errno=0x%x", errnoGet(),0,0,0,0,0);
}

删除任务时，推荐使用 taskSafe()/taskUnsafe() 保护临界资源，或采用事件标志通知任务自行退出。对于周期性任务，更推荐使用看门狗定时器（wdStart）触发，而非反复创建删除任务。

4.1.3 案例拆解：星务管理任务的生命周期控制

在某型号卫星的星务管理软件中，需要根据地面指令动态启停“高速数传任务”。初始设计直接调用 taskDelete() 终止任务，但在一次联试中发现：任务被删除时正持有 PCIe 总线访问信号量，导致后续其他任务访问总线时永久阻塞。分析日志显示，删除后信号量计数值始终为 0。

改进方案采用“软删除”机制：定义全局原子变量 stopFlag，数传任务在每个循环周期检查该标志，若置位则释放所有资源并调用 taskExit() 自行结束。同时，删除方通过信号量等待任务退出确认，超时则触发系统复位。该方案将删除操作从“强杀”变为“协作式退出”，彻底消除了资源泄漏风险。

风险提示：在航天环境中，任务删除必须考虑中断上下文。若在中断服务程序（ISR）中调用 taskDelete()，可能导致调度器状态不一致。VxWorks 规定 ISR 中只能发送信号量或事件通知，实际删除操作应延迟到任务上下文中执行。

4.2 任务状态机：就绪、阻塞、延时与挂起

4.2.1 状态定义与迁移条件

VxWorks 任务存在五种基本状态：READY（就绪）、PEND（阻塞等待信号量/消息）、DELAY（延时等待）、SUSPEND（挂起）以及它们之间的组合状态。状态迁移由内核调度器根据系统调用和事件触发。下表总结了主要状态迁移路径：

当前状态	触发事件	目标状态	典型系统调用
READY	被高优先级任务抢占	READY（队尾）	调度器自动
READY	等待信号量	PEND	semTake()
PEND	信号量释放	READY	semGive()
READY	调用延时	DELAY	taskDelay()
DELAY	延时到期	READY	tick 中断
任意状态	taskSuspend()	SUSPEND	taskSuspend()
SUSPEND	taskResume()	原状态	taskResume()

4.2.2 状态监控与调试方法

在航天软件联试阶段，常通过 taskStatusShow() 或 shell 命令 i 查看所有任务状态。当系统出现“假死”时，首先检查是否有任务长期处于 PEND 状态，这通常意味着死锁或信号量泄漏。VxWorks 提供 taskIdVerify() 验证任务 ID 合法性，taskTcb() 获取 TCB 指针用于深度检查。

经验：在星载软件中，建议每个任务在循环体内周期性调用 taskDelay(0)，这会让出 CPU 给同优先级任务，同时便于调试器观察任务是否“卡死”。若某任务长时间不执行 taskDelay，且其优先级较高，会饿死其他任务。

4.2.3 常见误区：SUSPEND 与 PEND 混淆

SUSPEND 是主动挂起，不释放已持有的资源；PEND 是等待资源而阻塞。初学者常误用 taskSuspend() 实现任务暂停，但若任务正持有互斥信号量，挂起会导致其他任务永久阻塞。正确做法是：需要暂停任务时，应通过事件标志或消息通知任务自行进入 PEND 状态。

4.3 优先级与调度算法：抢占式实时调度的工程实践

4.3.1 优先级抢占调度

VxWorks 默认采用基于优先级的抢占式调度（Priority-Based Preemptive Scheduling）。内核维护 256 个就绪队列，每个优先级对应一个队列。当高优先级任务就绪时，调度器立即保存当前任务上下文，切换到高优先级任务。该机制保证了关键任务的响应时间上界，但引入了优先级反转问题。

优先级反转的经典场景：低优先级任务持有信号量，高优先级任务等待该信号量，中优先级任务（不涉及该信号量）抢占低优先级任务，导致高优先级任务被间接阻塞。VxWorks 提供 semGive() 时的优先级继承机制（Priority Inheritance），当高优先级任务阻塞在信号量上时，持有信号量的任务临时提升到高优先级，直至释放信号量。

4.3.2 时间片轮转调度

对于同优先级任务，VxWorks 支持时间片轮转（Round-Robin）。通过 kernelTimeSlice() 设置时间片长度（默认 1 tick，即 16.67ms @60Hz）。当任务用完时间片后，被移到就绪队列尾部。该机制适用于多个非实时性任务共享 CPU，如遥测打包、日志记录等。

在航天应用中，时间片轮转需谨慎使用。若将姿态控制与轨道计算设为同优先级并启用轮转，可能导致控制周期抖动。推荐做法：实时性要求高的任务分配不同优先级，非实时任务才使用轮转。

4.3.3 案例拆解：某推进系统控制器的优先级分配

某型号推进系统控制器包含 4 个任务：阀门驱动（周期 10ms）、压力采集（周期 20ms）、故障诊断（事件触发）、遥测上报（周期 100ms）。初始设计将优先级设为：阀门驱动 60、压力采集 60、故障诊断 50、遥测上报 80。联试时发现阀门驱动偶尔超时，分析发现压力采集与阀门驱动同优先级，时间片轮转导致阀门驱动被延迟。

优化方案：将阀门驱动优先级提升至 40，压力采集保持 60，故障诊断设为 50（高于采集低于驱动），遥测上报设为 80。同时，阀门驱动内使用 semTake(..., WAIT_FOREVER) 等待 10ms 周期信号，确保严格周期。优化后，阀门驱动最大响应时间从 23ms 降至 11ms，满足 10ms 周期要求。

调度参数配置清单：
优先级分配原则：中断处理 > 周期控制 > 事件处理 > 数据采集 > 遥测/日志
时间片仅用于同优先级非实时任务，默认关闭
启用优先级继承：semGive() 时自动生效，无需额外配置
使用 taskPrioritySet() 动态调整优先级需谨慎，仅在特定阶段（如模式切换）使用

4.4 任务同步与通信：信号量、消息队列与事件

4.4.1 同步机制对比与选型

任务同步解决“谁先谁后”的问题，通信解决“数据如何传递”的问题。VxWorks 提供三类主要机制：信号量（Semaphore）、消息队列（Message Queue）、事件（Event）。下表对比了它们的适用场景：

机制	类型	典型用途	特点	航天应用示例
二值信号量	同步/互斥	互斥访问共享资源	只有 0/1 两态，支持优先级继承	保护 AD 采集寄存器
计数信号量	资源计数	管理多个同类资源	计数值可累加	管理 DMA 通道池
互斥信号量	互斥	临界区保护	支持递归获取、优先级继承	保护轨道参数数据库
消息队列	数据通信	任务间传递数据块	支持变长消息、多发送者	地面指令分发
事件	多条件同步	等待多个事件同时发生	32 位事件标志，支持与/或	等待“加电完成+自检通过”

4.4.2 消息队列的工程实现

消息队列通过 msgQCreate() 创建，需指定最大消息数和消息长度。在航天软件中，消息队列的深度必须根据最坏情况下的消息积压量计算。例如，遥测任务每秒产生 50 条消息，地面指令突发时可能 1 秒内到达 200 条，队列深度至少设为 256 条，并配合超时机制防止发送方无限阻塞。

/* 创建指令消息队列，最多 64 条，每条 128 字节 */
MSG_Q_ID cmdQ = msgQCreate(64, 128, MSG_Q_FIFO);
/* 发送消息，超时 100 tick */
if (msgQSend(cmdQ, (char *)&cmd, sizeof(cmd), 100, MSG_PRI_NORMAL) == ERROR) {
    logMsg("msgQSend failed, queue full",0,0,0,0,0,0);
}

4.4.3 案例拆解：姿轨控计算机的指令分发与遥测汇聚

在某姿轨控计算机中，星务主机通过 1553B 总线发送指令，本机接收后需分发给姿态控制、轨道计算、热控三个任务。初始设计采用三个独立消息队列，但发现指令顺序无法保证——当同时到达多条指令时，不同队列的处理顺序可能颠倒。

重构方案：采用单一消息队列接收所有指令，由分发任务根据指令类型调用 msgQSend() 转发到对应任务。同时，遥测数据汇聚采用“事件+共享缓冲区”模式：各任务采集数据后写入预分配缓冲区，置位对应事件位，遥测任务等待所有事件就绪后统一打包。该设计将指令顺序问题彻底解决，且遥测打包周期从 50ms 缩短至 30ms。

死锁预防：当任务同时持有多个信号量时，必须按固定顺序获取（如先取 A 再取 B），释放时按相反顺序。否则两个任务互相等待对方持有的信号量，形成死锁。在代码审查中，应使用静态工具检查信号量获取顺序是否一致。

4.5 任务管理综合设计建议与复盘

在航天项目实践中，任务管理设计应遵循以下原则：第一，任务划分以功能内聚为准则，避免一个任务承担过多职责；第二，优先级分配需经过响应时间分析（RTA），确保最坏情况下关键任务满足截止时间；第三，所有同步与通信机制必须考虑超时和错误恢复路径，防止单点故障导致系统挂起；第四，任务栈大小需通过静态分析工具（如 Stack Usage）验证，并在运行时监控栈水位。

典型的设计复盘案例：某型号在初样阶段出现偶发性任务超时，排查发现是某任务在异常分支中未释放信号量，导致其他任务 PEND 超时。通过在信号量获取处增加超时参数（如 semTake(sem, 100)），并在超时后执行恢复流程（重置外设、重启任务），系统鲁棒性显著提升。这一经验表明，任务管理不仅是调度问题，更是系统级容错设计的重要组成部分。

最后，建议在 VxWorks 工程中启用 INCLUDE_TASK_HOOKS，注册任务创建/删除钩子函数，用于监控任务数量变化和内存泄漏。在卫星长期在轨运行中，任务数量的异常增长往往是资源泄漏的前兆，通过钩子函数记录任务创建时的调用栈，可快速定位泄漏源。