4.1 队列：内核通信的基石

4.1 队列：内核通信的基石

本节摘要：队列是 FreeRTOS 最核心的通信原语——定长元素、先进先出、复制语义，任务与中断都能安全使用。本节拆解队列的内部结构（一块存储区加两条等待链表），讲清发送与接收的阻塞超时行为、"满时谁让路"的细节、中断安全版本的正确用法，最后用一套采集到显示的数据通路演示队列在真实拓扑中的用法与调参。读懂队列，全族原语的理解就完成了一半——因为信号量与互斥量都是用队列结构实现的。

多任务系统里最频繁的需求很简单：把数据从一个执行流搬到另一个执行流。任务甲算出一个结果，任务乙要用；中断收到一个字节，任务要处理。直接用全局变量行不行？行，但你得自己解决 3.3 节的全部竞争问题，还要解决"乙什么时候知道数据来了"。队列把这两件事打包：数据按序搬运、等待者自动阻塞——它就是你与内核之间签订的第一份通信契约。

一、复制语义：一次搬家的安全感

队列的创建要声明两件事：队列深度（最多放几个元素）与元素大小（每个元素几个字节）。发送时内核把你的数据按字节复制进队列存储区，接收时再复制出去。这个"复制而非传引用"的设计常被初学者嫌浪费，但它是线程安全的根基：数据进队那一刻起，发送方的原件与队列里的副本彻底脱钩——发送方随手改写、释放原件，都不影响接收方拿到完整数据。传引用的做法则要回答"谁管引用对象的生命周期"这个经典难题，在无内存保护的嵌入式环境里，答案是"没人管得起"。

代价同样明确：两次复制的时间与元素大小成正比。搬一个四字节的结构体毫无压力；搬一张摄像头帧（几万字节）就是灾难——大块数据的标准做法是队列里放指针，数据本体放在专用的缓冲区管理模块里（谁分配、谁释放、怎么回收，规则要明确）。队列搬小数据，指针加大缓冲搬大数据，这是第一工程守则。

二、内部结构：一块存储区两条链表

剥开队列结构体，核心就三样：环形排列的存储区、发送等待链表、接收等待链表。发送方发现队列已满就挂到发送等待链表（等空位），接收方发现队列已空就挂到接收等待链表（等数据）。所有阻塞都带期限（超时参数），到期带着"超时"结果醒来。两条链表按优先级排序——队列腾出一个空位时，唤醒的是等待者里优先级最高的那个，而不是最早排队的那个，实时系统的逻辑贯穿到每个角落。

队列内部结构与数据流

一个容易忽视的细节藏在临界区里：发送与接收的实现内部都要进临界区保护链表操作，若在临界区内直接唤醒等待任务再切换，临界区会被拉长。内核的做法是给队列配一把"锁计数"——临界区内只把待处理的唤醒记在账上，出了临界区再统一结算唤醒。这个设计你无需使用，但排障时解释"为什么发送后高优先级任务不是立刻跑，而是晚了几微秒"就会用到。

三、阻塞、超时与让路规则

发送与接收都带一个超时参数，四种典型取值对应四种行为：零（不等待，成败立判）、短超时（稍等即返）、长超时（耐心等待）、无限期（等到天荒地老，慎用——等错了对象就是永久卡死，工单见第 8 章）。返回值必须检查，它是"成功、超时、参数错"三态的唯一出口。

"满时谁让路"值得单独说：队列满、发送者阻塞，此刻接收者取走一个元素，发送者被唤醒——但唤醒不等于运行，它要先跟当时在跑的任务比优先级。所以高优先级发送者被低优先级接收者"救醒"的场景里，切换立刻发生；反过来则要等接收者阻塞或让出。把这条规则与 2.3 节的两条法条对照着看，任何队列交互的时序都能推演出来。

typedef struct { uint16_t raw; uint32_t ts; } Sample_t;   /* 小数据直接进队 */

void producer_task(void *arg)
{
    QueueHandle_t q = (QueueHandle_t)arg;
    Sample_t s;
    for (;;) {
        s.raw = adc_read();
        s.ts  = xTaskGetTickCount();
        if (xQueueSend(q, &s, pdMS_TO_TICKS(10)) != pdPASS) {
            count_drop();            /* 短超时 + 丢弃计数：过载时的背压策略 */
        }
    }
}

void consumer_task(void *arg)
{
    QueueHandle_t q = (QueueHandle_t)arg;
    Sample_t s;
    for (;;) {
        if (xQueueReceive(q, &s, portMAX_DELAY) == pdPASS) {   /* 醒来必有数据 */
            process(&s);
        }
    }
}
​

这段代码里藏着两个设计决策。生产者用短超时加丢弃计数而不是无限期等待：消费端过载时宁可丢样本也不让采集任务卡死——这是背压策略的一种（还有"覆盖最新"与"挤掉最旧"两个变体，队列族提供了对应接口）。消费者用无限期等待：它的存在意义就是消化队列，空等是本分。同一个参数，因角色而异。

四、中断里的队列：三步标准动作

中断要用队列时，必须换用中断安全版本，并遵守三步标准动作：

void UART_IRQHandler(void)
{
    BaseType_t xWoken = pdFALSE;                    /* 步骤一：本地旗子置否 */
    uint8_t byte = uart_dr();

    xQueueSendFromISR(xByteQ, &byte, &xWoken);      /* 步骤二：用带后缀接口 */

    portYIELD_FROM_ISR(xWoken);                     /* 步骤三：按旗子请求切换 */
}
​

为什么必须是这样？中断不属于任何任务，"阻塞"无从谈起（2.2 节），所以中断版接口没有超时参数、永不等待——放不进就返回失败，由你决定重试或丢弃。旗子变量的作用是记账：如果这次发送唤醒了一个比被打断任务优先级更高的任务，接口把它置为真；退出中断前按旗子请求一次切换，让高优先级任务立刻接管。漏掉第三步的典型症状是"延迟偶发变大一整段"——唤醒发生了，切换却要等到下一个滴答，时序分析时极难定位。

⚠️ 队列相关的三个高频坑：其一，元素大小与结构体对不上（打包与解包双方声明不一致，拿到错位数据）——用同一头文件里的类型定义杜绝；其二，在中断里调用了不带后缀的版本（3.4 节坑四的通用形态）；其三，把队列深度当成"越大越好"——深度过大掩盖生产消费失衡，问题从"丢数据"变成"延迟尖峰"，更隐蔽。深度按"过载窗口内允许积压多少"计算，而不是内存能塞多少。

五、案例：一条采集到显示的通路

背景：传感器以毫秒级产样本，显示任务以百毫秒级刷新，中间还要经过滤波任务。设计：三段流水线，两队列连接，队列元素都是小结构体；滤波到显示的队列用"挤掉最旧"策略（显示要的是最新状态，旧样本无价值）。结果：整机满负荷时采集零丢失、显示始终新鲜。解读：两段队列用了两种溢出策略，差别源于下游语义——滤波段要全量（丢一个样本滤波就偏），显示段要新鲜（旧的该死）。变式：若显示改为一秒一帧的超低频，挤掉最旧依旧成立；若中间加入记录任务（要全量落盘），它必须接在全量分支上并自带限速策略，否则一个慢速存储拖垮整条线。

本节要点回顾

• 复制语义是安全的根基：小数据直接进队，大数据传指针配缓冲管理，两套打法各守其位；
• 一块存储区两条链表：等待者按优先级排队，唤醒高优先级者优先，超时结果走返回值；
• 超时参数按角色定：生产者短超时加丢弃计数做背压，消费者无限期等待是本分；
• 中断三步标准动作：旗子置否、带后缀接口、按旗子请求切换，漏第三步延迟偶发膨胀；
• 队列深度按过载窗口算，过大只是把丢失换成延迟尖峰；
• 原语是全族地基：下一节的信号量与互斥量，内部就是一条特殊配置的队列。

队列搬数据没问题了，但"占用资源"是另一类需求——两台电机只能同时一台上电、一段共享内存只能一人写。这类需求该用什么？下一节从一张"高优先级任务反而迟到"的工单说起，答案与陷阱都在里面。