4. 任务间通信机制：队列、信号量、互斥量、事件标志组、消息邮箱的原理与选型
各位同学，咱们今天聊聊任务间通信。说实话，这是RTOS里最核心、也最容易踩坑的地方。你想想看，一个自动驾驶系统里，少说几十个任务在跑，摄像头采集、激光雷达处理、路径规划、控制输出……它们之间怎么交换数据？怎么同步动作？这就是通信机制要解决的问题。
我个人习惯把通信机制分成两类：数据传递和同步控制。队列和消息邮箱负责搬数据，信号量和事件标志组负责发信号。互斥量呢？它是个特殊的存在，专门用来保护共享资源。咱们一个一个说。
4.1 队列（Queue）——最常用的数据管道
队列，说白了就是一个先进先出的缓冲区。一个任务往里写，另一个任务往外读。我在项目中遇到过最典型的场景：CAN总线接收中断里，把收到的报文塞进队列，然后让一个专门的任务去解析处理。这样中断服务程序就能快速退出，不会阻塞其他中断。
核心要点：
- 队列是拷贝传递的。你发送的数据会被复制到队列内部缓冲区。所以别传太大的结构体，否则内存和CPU都吃不消。
- 支持超时等待。读队列时可以设置等待时间，比如等10毫秒，超时了就返回错误。这比死等要优雅得多。
- 队列长度要精心设计。太短容易丢数据，太长浪费内存。我一般按峰值速率的2-3倍来估算。
// FreeRTOS 队列示例
QueueHandle_t xCANQueue;
// 创建队列，每个元素20字节，深度10
xCANQueue = xQueueCreate(10, sizeof(CAN_Message_t));
// 发送任务
void CAN_Task(void *pvParameters) {
CAN_Message_t msg;
while(1) {
// 从硬件读取CAN报文
CAN_Read(&msg);
// 发送到队列，等0ms，满了就丢弃
xQueueSend(xCANQueue, &msg, 0);
}
}
// 接收任务
void Process_Task(void *pvParameters) {
CAN_Message_t msg;
while(1) {
// 阻塞等待，直到收到数据
if(xQueueReceive(xCANQueue, &msg, portMAX_DELAY) == pdPASS) {
ProcessCANMessage(&msg);
}
}
}
我的经验：队列的拷贝开销在高速场景下不可忽视。比如激光雷达每秒30帧，每帧几万个点云数据。这时候用队列拷贝就不太合适了。我通常改用消息指针队列——队列里只存指针，数据本身放在共享内存池里。这样拷贝成本就降下来了。
4.2 信号量（Semaphore）——轻量级的同步工具
信号量分两种：二值信号量和计数信号量。二值信号量就像一把钥匙，谁拿到谁干活。计数信号量更像一个停车场计数器，记录还有多少个空位。
我记得有一次调试一个传感器驱动，中断里用信号量通知处理任务。结果发现任务偶尔会漏掉中断。查了半天，原来是中断太快，信号量还没来得及释放，下一个中断又来了。二值信号量在这种情况下会丢失事件。后来我改成了计数信号量，每次中断都give一次，任务再take多次，问题就解决了。
避坑指南：我曾经在中断服务程序里调用信号量的take操作，结果系统直接死机。记住：中断里只能give，不能take。因为take可能会导致任务阻塞，而中断上下文是不允许阻塞的。
4.3 互斥量（Mutex）——保护共享资源的利器
互斥量和二值信号量看起来很像，但有个关键区别：优先级继承。什么意思呢？假设低优先级任务拿着锁，高优先级任务在等锁。如果没有优先级继承，低优先级任务可能被中优先级任务抢占，导致高优先级任务无限等待——这就是经典的优先级反转问题。
互斥量会自动把低优先级任务的优先级临时提升到和高优先级任务一样，等它释放锁后再降回去。这个机制在自动驾驶里特别重要。比如路径规划任务（高优先级）和日志记录任务（低优先级）都要访问地图数据，没有优先级继承的话，后果不堪设想。
| 特性 | 互斥量 | 二值信号量 |
|---|---|---|
| 优先级继承 | 支持 | 不支持 |
| 典型用途 | 保护共享资源 | 任务同步 |
| 谁可以释放 | 只能由持有者释放 | 任何任务都可以 |
| 中断中使用 | 不允许 | 只能give |
选型建议：保护共享资源时，优先用互斥量。如果只是做简单的任务同步（比如中断通知任务干活），用二值信号量就够了，别杀鸡用牛刀。
4.4 事件标志组（Event Group）——多条件同步
事件标志组，说白了就是一个32位的位图。每个位代表一个事件。任务可以等待多个事件同时发生（与模式），或者任意一个发生（或模式）。
我在项目中用过它来同步多个传感器数据。比如融合算法需要同时拿到摄像头、雷达、激光雷达的数据才能开始计算。用事件标志组就很方便：每个传感器任务完成采集后，设置对应的位。融合任务等待所有位都置1，然后一次性处理。
// 事件标志组示例
EventGroupHandle_t xSensorEventGroup;
#define CAMERA_BIT (1 << 0)
#define RADAR_BIT (1 << 1)
#define LIDAR_BIT (1 << 2)
// 融合任务
void Fusion_Task(void *pvParameters) {
EventBits_t uxBits;
while(1) {
// 等待所有三个传感器数据就绪
uxBits = xEventGroupWaitBits(
xSensorEventGroup,
CAMERA_BIT | RADAR_BIT | LIDAR_BIT,
pdTRUE, // 读取后自动清除
pdTRUE, // 等待所有位
portMAX_DELAY
);
// 开始融合计算
SensorFusion();
}
}
注意：事件标志组最多支持24个用户定义的事件位（有些RTOS是32位）。如果你的事件数量超过这个数，就得考虑用多个事件标志组，或者改用队列传递事件消息了。
4.5 消息邮箱（Message Mailbox）——轻量级消息传递
消息邮箱，有些RTOS里也叫消息缓冲。它和队列的区别在于：邮箱通常只存一条消息，新消息会覆盖旧消息。而队列可以存多条。
你想想看，什么场景下用邮箱合适？比如系统状态信息。当前车速、电池电量、GPS坐标……这些信息只需要最新的值，旧值没有保留意义。用邮箱就比用队列更省内存，也更简单。
选型对比：
- 队列：适合数据流，需要缓冲，不能丢数据。比如CAN报文、串口数据。
- 邮箱：适合状态值，只关心最新值。比如车辆速度、方向盘角度。
- 信号量：适合事件通知，不传递数据。比如中断触发任务。
- 互斥量：保护共享资源，防止竞争条件。
- 事件标志组：多条件同步，等待多个事件同时发生。
4.6 选型总结——我的决策框架
好了，五种机制都讲完了。你可能会问：这么多选择，到底用哪个？我分享一下自己的决策流程：
- 先问自己：我需要传递数据吗？
- 需要 → 用队列或邮箱
- 不需要 → 用信号量或事件标志组
- 如果需要传递数据：数据需要缓冲吗？
- 需要缓冲，不能丢 → 队列
- 只关心最新值 → 邮箱
- 如果不需要传递数据：是单事件还是多事件？
- 单事件触发 → 信号量
- 多事件同步 → 事件标志组
- 最后检查：有没有共享资源需要保护？
- 有 → 加互斥量
嗯，这个框架我用了好多年，基本没出过问题。当然，实际项目中往往需要组合使用。比如一个任务可能同时等待事件标志组，又通过队列接收数据。这都很正常，灵活运用就好。
最后提醒一句：别滥用通信机制。我见过有人为了省事，把所有任务之间的交互都塞进一个全局队列里。结果系统变得又慢又难调试。记住：通信机制是工具，不是目的。设计时先想清楚数据流和控制流，再选择合适的工具。
好了，这一章就到这里。下一章咱们聊聊内存管理——堆栈分配、内存池、动态内存和静态内存的选择。这些在自动驾驶系统里也是容易出问题的地方。