共计 1686 个字符，预计需要花费 5 分钟才能阅读完成。
本文由 RT-Thread 论坛用户 @出出啊原创公布：https://club.rt-thread.org/as…
前言
系统优化系列先停一停，总对人指指点点会让大家恶感的。明天给各位 rt-thread 使用者一些应用信号量、邮箱、音讯队列等同步和通信机制的倡议。
线程间同步概念
摘取 RT-Thread 官网文档核心对“线程间同步”的解说。
同步是指按预约的先后秩序进行运行，线程同步是指多个线程通过特定的机制（如互斥量，事件对象，临界区）来控制线程之间的执行程序，也能够说是在线程之间通过同步建设起执行程序的关系，如果没有同步，那线程之间将是无序的。多个线程操作 / 拜访同一块区域（代码），这块代码就称为临界区，上述例子中的共享内存块就是临界区。线程互斥是指对于临界区资源拜访的排它性。当多个线程都要应用临界区资源时，任何时刻最多只容许一个线程去应用，其它要应用该资源的线程必须期待，直到占用资源者开释该资源。线程互斥能够看成是一种非凡的线程同步。线程间同步的形式包含但不限于信号量、互斥量、事件集等。
线程间通信概念
说线程间同步使得不同线程的执行变得有序、有规有矩，防止了临界区的竞争拜访。那么，线程间通信让多线程之间更“智能”。
线程间通信的形式包含但不限于邮箱、音讯队列、信号
两种应用场景
毋庸置疑的，所有同步和通信机制都是为线程（工作）而生的。没有同步和通信的多线程是人心涣散。在线程里调用同步和通信 API，这是第一种应用场景。
第二种应用场景：中断向线程发送信号量、事件集、邮箱、音讯队列。（互斥量千万不要在中断里应用）
我想，少数人应用过中断向线程 release / send 信号量或音讯队列。从业务逻辑上讲，把中断等价于一个“线程”给另一个线程发送信号量等也是说得过去的。
然而，少数使用者疏忽了一个问题，那就是，线程间同步和通信机制发送 API 无一例外会调用 rt_schedule 函数（任务调度）。尽管在中断里调用 rt_schedule 不会立马切换线程。然而，这无疑是减少中断解决任务量的！另外，还有一个值得须要思考的问题，如果立马进行任务调度，有没有从高优先级切换到低优先级线程的危险？
由此，可能引起某些非预期结果，上面分两种状况剖析。
当中断频度低，或者零碎中断类型比拟少的状况下，中断解决工夫长短对业务影响不是很显著。例如行程开关的 gpio 中断，秒级或者分钟级工夫周期才产生一次中断。
当中断频度高，或者零碎中有多个比拟频繁的中断类型。中断解决工夫过长，可能引起同（低）优先级中断失落。例如 115200 波特率的串口中断里应用 rt_sem_release 或者 rt_mq_send 时，得思考一个问题了，串口接管中断处理函数最大解决工夫超过 86us 了吗？
通信机制虽好，请勿随便应用。
中断接管解决的几点倡议
集体倡议，在中断中应用信号量或音讯队列等机制时先考虑一下
中断频度在 10ms 以下，审慎应用，1ms 以下就思考其它形式吧。开启 DMA，DMA 是个好货色，因为有缓存，对中断解决的任务量要求小很多。应用原子类型做数据非空标识。惋惜目前 rt-thread 没有提供原子类型的实现接口，不过咱们能够用整型变量 f 代替（少数芯片架构下是可行的），中断接收数据放到用户 fifo 里，同时置位变量 f。线程里轮询变量 f 是否扭转，检测到扭转后立马复位变量 f，而后获取 filo 数据量，出栈数据。
能够保障的是，检测 f 是否扭转不须要关中断，复位 f 时才须要短时间关中断，fifo 出栈数据也有极短的关中断工夫。这些都比进行任务调度的 cpu 开销少。惟一有余是轮询检测的过程占用 cpu 高，怎么升高轮询的 cpu 占用？能够尝试一下 rt_thread_yield rt_schedule。
总结
线程间同步和线程间通信机制虽好，然而并不是什么时候都能应用的。咱们都晓得中断里不能应用互斥量，然而疏忽了，高频中断里应用同步和通信带来的隐形影响。
rtos 并没有让中断的应用更不便，相同，相比裸机，减少了更多留神点和应用限度。
相互分享，共同进步！充电结束后，也别忘记来分享噢，RT-Thread 每月都有原创文章征集流动，激励大家多多分享技术文章！
