任务同步总结及环状同步造成的死锁

任务同步总结及环状同步造成的死锁

概述

任务之间通过通信约定了执行的步骤的过程称为同步。关于同步，我们从全局变量讲起、逐步引入了二值信号量、计数信号量、事件组、队列这些通信组件。

将这些通信组件用于同步时，需要根据实际情况进行选择：

1）当同步过程不需要传输具体内容时，可以选择信号量、事件组进行同步。

2）当同步需要传递具体消息时，可以选择队列进行通信

3）当“生产者”生产消息的速度比“消费者”使用消息的速率慢时，可以选择没有计数、缓存能力的二值信号量、事件组。

4）对于非周期性同步需求，当不满足“生产者”生产消息的速度比“消费者”使用消息的速率慢时，可以选择具有一定缓冲能力的通信组件（计数信号量、队列）

5）当同步信号是多个信号的逻辑关系时，可以选择具备逻辑筛选功能的事件组进行通信。

此外，关于同步我们还可以将其做以下分类，方便在选择同步方法时加以考虑：

从同步的数量看，可以分为双任务同步、多任务同步。

从同步关系上看，可以分为单向同步、双向同步。

从同步内容上看，可以分为仅通知，通知+传递数据。

需求及功能解析

同步关系往往是程序设计者通过需求分析进行设计的，好的同步关系可以保证设备的实时性、稳定性。然而，由于程序运行后，系统发生的情况总是对变的，系统很有可能因复杂的同步关系进入一种错误的运行状态。其中一种称为"死锁"的状态就是容易出现的错误之一。

死锁：多个任务，每个任务都需要一定的条件才能触发执行。但这些任务之间存在一定的依赖关系，导致出现互相等待的情况，最终每一个任务都无法执行下去：

引起死锁的主要是资源竞争和环路同步等待这两种情况。本质是相同的，同步消息也可以看作一种资源。本节的示例仅演示环路同步造成的死锁。后续将在资源共享篇讨论另一种情况。

示例解析

示例通过三个任务之间互相等待信号量来演示这种环路同步造成的死锁。死锁发生时，环路里的每个任务都无法正常运行，相关系统功能完全死机。

This is esp32 chip with 2 CPU core(s), WiFi/BT/BLE, Minimum free heap size: 295332 bytes
TASK2: wait fo sem2, and then notify sem3, flag=0
TASK1: wait fo sem1, and then notify sem2, flag=0
TASK3: wait fo sem3, and then notify sem1, flag=0

讨论

死锁的主要是：资源的独占、循环等待引起的。在设计的时候，主要是要充分分析进行避免，设计检测和恢复机制来处理这种可能的异常。

总结

1）任务之间可以通信，通信的目的可以是同步执行流程或者传递数据。关于同步，可以通过全局变量、二值信号量、计数信号量、事件组、消息队列这些实现同步，它们的特点不同，在选择时应充分考虑同步的需求进行选择。

2）任务同步可能因环路同步发生死锁。为避免死锁发生，可以通过在设计时进行充分分析进行避免，或者设计检测和恢复机制来处理这种可能的异常。

资源链接

1）Learning-FreeRTOS-with-esp32 系列博客介绍
2）对应示例的 code 链接 （点击直达代码仓库）

3）下一篇：使用全局变量实现数据通信（传递）