FreeRTOS 互斥信号量和二值信号量对比

互斥信号量

1.有优先级继承。

2.尽量不要在中断中调用

3.xSemaphoreCreateMutex创建后，可以直接take使用。

二值信号量

1.无优先级继承。

2.允许在中断中调用。

3.可以当做标志位来使用。

4.xSemaphoreCreateBinary创建后，必须得先give一下才能被take。

这么说其实很笼统，直接代码测试。

这里使用的是互斥信号量。

1.创建两个测试任务，app_mqtt_get_properties_handle_task和app_mqtt_set_properties_handle_task

2.两个任务内容

这两个任务其实没做什么动作。就是在take give 然后就挂起等待。

任务1：take，等待200ms，give ，等待200ms。

任务2：take，等待1000ms，give，等待200ms。

理论上来说任何一个任务take了之后，另外一个任务就无法take，必须等待give之后。直接上输出结果。

这里把take before和after，give before和after都打印出来。看箭头的位置，任务1 take before，当时的时间是28931。接下来任务2 give before，时间是29725.中间有800ms的时间差。这个就是任务1在等待任务2 give信号量。

如果把代码中的互斥信号量换成二值信号量，输出的结果是一样的。那就有个疑问了。为什么会一样呢？说白了，不管是互斥信号量还是二值信号量，都是信号量。互斥信号量是二值信号量的子集。他们的应用场景是不同的。但是在如上代码的应用场景中，是没有区别的。因为是把他们当信号量来使用了，所以结果也是相同的。

那这两者的不同之处在哪里呢？

最大的区别就是互斥信号量解决了优先级翻转的问题。这里直接引用别人的文章内容：

二值信号量和互斥锁到底有什么区别？ - 代码螺丝钉 - 博客园

假定我们现在有三个任务，task1，task2，task3，任务优先级task1最高，然后依次降低。我们知道在系统调度的时候当两个任务同时处于就绪态的时候，系统会优先执行优先级高的任务

优先级翻转分析(使用信号量)

---

 在例子中，我们使用pend()函数来表示获取信号量，用post()函数来表示释放信号量

如上图所示，过程分下面几步

1.一开始task3开始运行，先获取到信号量

2.task1开始运行尝试去获取信号量失败被阻塞等待task3执行完

3.task3运行过程中，task2被触发，由于其优先级高于task3，task2被运行，浪费了大量时间

4.继续运行task3，运行完后释放信号量

5.task1继续运行

看到这里我们可以得知，本应该优先级最高的task1结果居然是最后开始运行的，这就是优先级反转现象。这明显是不利的。比如如果有安装看门狗，task1在长时间没有得到执行，就会触发看门狗，导致系统的重启。

改进分析(使用互斥锁)

---

  在例子中，我们使用lock()函数来表示获取互斥锁，用unlock()函数来表示释放互斥锁

 

如上图所示，过程分下面几步

1.一开始task3开始运行，先获取到互斥锁

2.task1开始运行尝试去获取互斥锁失败被阻塞等待task3执行完，但是此时提升task3的优先级，让其优先级跟自己一样

3.task3运行过程中，task2被触发，由于其优先级低于task3(第2步被提升过)，task2等待运行

4.继续运行task3，运行完后释放互斥锁

5.task1继续运行

6.task1执行完，执行task2

所以过程跟前面的虽然一样，但是互斥锁多做了一个步骤就是将task3的优先级提升到task1的级别，防止task2中途出来搅局浪费大量时间。

说到底，其实就是两个信号量的应用场景不同。互斥信号量是防止出现优先级翻转导致卡死的情况。这个的前提是一个公共资源被多个任务调用的情况下。如果没有这种情况，二值信号量就可以应对。就像一个标志位一样。