RTOS多任务传数据：全局变量、环形buffer和队列

Thu, 17 Sep 2026 19:40:08 +0800

多任务间传输数据常用的做法有三种：全局变量、环形buffer、队列。

全局变量

全局变量实现起来最方便，但是有硬伤：

环形buffer本质就是一个数组+两个下标（r+w），在逻辑上把数组首尾接成环。环形buffer是提供给生产者-消费者模式的两个任务用的。

如果 r==w，环形buffer就是空的。因此环形buffer数组的格子不能用完，因为用完也是 r==w 了，也就是用1个格子换来了空和满不歧义。

环形buffer不要加 count，因为一旦加上这个变量，消费者和生产者两个任务就有可能同时写这个变量，而 count++ 在CPU上通常不是原子的：

同样地，环形buffer也没有阻塞唤醒，需要任务自己去判断，可能会造成忙等。

可以把队列理解为加了互斥保护和阻塞唤醒的环形buffer。

有了互斥保护，环形buffer中不敢用的 count 在队列中能用了。也因为有了互斥保护，队列是可以多读多写的，不像环形buffer那样只支持生产者-消费者两个任务一读一写。

队列内部其实有三样东西：

写队列成功后，会看 receiver list 里有没有任务，有就把第一个移动回就绪链表。同样地，读队列成功后，会看 send list 中有没有任务，有就把第一个移动回就绪链表。就是用这种方式，队列实现了阻塞唤醒。

读到空队列的时候，任务会被同时挂到两个地方：

所以一个阻塞中的读队列任务，会同时出现在两条链表里。

然后分为两种唤醒路径：

写满队列的情况也是对称的。

这种情况是不会发生的，因为超时检查和操作队列都会先进入内核的临界区，会关中断、锁调度，保证了别的改队列的代码要等待当前这段代码执行完成。这种临界区不是高级语言的那种 mutex 临界区，而是通过关中断实现的。一旦关中断，所有的代码都无法抢占运行了。也因为这样，关中断内执行的操作必须要短时间完成。

更关键的是：读队列不是“被叫醒就立刻带着某种结果返回”，而是醒了再看一眼队列里到底有没有东西：如果有东西，就当作是成功了，把数据拿走然后返回。如果是空的，就可以确认是超时醒来的，会返回错误码。