前言

系统优化系列先停一停，总对人指指点点会让大家反感的。今天给各位 rt-thread 使用者一些使用信号量、邮箱、消息队列等同步和通信机制的建议。

线程间同步概念

摘取 RT-Thread 官方文档中心对“线程间同步”的讲解。

同步是指按预定的先后次序进行运行，线程同步是指多个线程通过特定的机制（如互斥量，事件对象，临界区）来控制线程之间的执行顺序，也可以说是在线程之间通过同步建立起执行顺序的关系，如果没有同步，那线程之间将是无序的。
多个线程操作 / 访问同一块区域（代码），这块代码就称为临界区，上述例子中的共享内存块就是临界区。线程互斥是指对于临界区资源访问的排它性。当多个线程都要使用临界区资源时，任何时刻最多只允许一个线程去使用，其它要使用该资源的线程必须等待，直到占用资源者释放该资源。线程互斥可以看成是一种特殊的线程同步。

线程间同步的方式包括但不限于信号量、互斥量、事件集等。

线程间通信概念

说线程间同步使得不同线程的执行变得有序、有规有矩，避免了临界区的竞争访问。那么，线程间通信让多线程之间更“智能”。
线程间通信的方式包括但不限于邮箱、消息队列、信号

两种使用场景

毋庸置疑的，所有同步和通信机制都是为线程（任务）而生的。没有同步和通信的多线程是一盘散沙。在线程里调用同步和通信 API ，这是第一种使用场景。

第二种使用场景：中断向线程发送信号量、事件集、邮箱、消息队列。（互斥量千万不要在中断里使用）
我想，多数人使用过中断向线程 release / send 信号量或消息队列。从业务逻辑上讲，把中断等价于一个“线程”给另一个线程发送信号量等也是说得过去的。

但是，多数使用者忽略了一个问题，那就是，线程间同步和通信机制发送 API 无一例外会调用 rt_schedule 函数（任务调度）。虽然在中断里调用 rt_schedule 不会立马切换线程。但是，这无疑是增加中断处理任务量的！另外，还有一个值得需要考虑的问题，如果立马进行任务调度，有没有从高优先级切换到低优先级线程的风险？

由此，可能引起某些非预期后果，下面分两种情况分析。

当中断频度低，或者系统中断类型比较少的情况下，中断处理时间长短对业务影响不是很明显。例如行程开关的gpio中断，秒级或者分钟级时间周期才产生一次中断。

当中断频度高，或者系统中有多个比较频繁的中断类型。中断处理时间过长，可能引起同（低）优先级中断丢失。例如 115200 波特率的串口中断里使用 rt_sem_release 或者 rt_mq_send 时，得考虑一个问题了，串口接收中断处理函数最大处理时间超过 86us 了吗？

通信机制虽好，请勿随意使用。

中断接收处理的几点建议

个人建议，在中断中使用信号量或消息队列等机制时先考虑一下

1. 中断频度在 10ms 以下，谨慎使用，1ms 以下就考虑其它方式吧。
2. 开启 DMA ，DMA 是个好东西，因为有缓存，对中断处理的任务量要求小很多。
3. 使用原子类型做数据非空标识。

可惜目前 rt-thread 没有提供原子类型的实现接口，不过我们可以用整型变量 f 代替（多数芯片架构下是可行的），中断接收数据放到用户 fifo 里，同时置位变量 f。线程里轮询变量 f 是否改变，检测到改变后立马复位变量 f，然后获取 filo 数据量，出栈数据。
可以保证的是，检测 f 是否改变不需要关中断，复位 f 时才需要短时间关中断，fifo 出栈数据也有极短的关中断时间。这些都比进行任务调度的 cpu 开销少。唯一不足是轮询检测的过程占用 cpu 高，怎么降低轮询的 cpu 占用？可以尝试一下 rt_thread_yield rt_schedule 。

总结

线程间同步和线程间通信机制虽好，但是并不是什么时候都能使用的。我们都知道中断里不能使用互斥量，但是忽略了，高频中断里使用同步和通信带来的隐形影响。
rtos 并没有让中断的使用更方便，相反，相比裸机，增加了更多注意点和使用限制。