1819_ChibiOS的互斥信号与条件变量

         全部学习汇总： GreyZhang/g_ChibiOS: I found a new RTOS called ChibiOS and it seems interesting! (github.com)

1. 关于会吃信号与条件变量的全局配置提供了4个配置信息，分别是互斥信号的使能、互斥信号的递归支持、条件变量的使能、条件变量的超时使能。

2. 不同于一般的信号量，互斥信号是全都绑定线程的。

3. 针对互斥信号的递归操作是指，同一线程可以多次锁定信号，但是也要解锁对应的次数才能够允许其他的线程获取。

1. 互斥信号绑定了两个信息，其中一个是拥有互斥信号的线程引用，另一个是等待线程的引用队列。

2. 在API提供方面，提供了try功能的安全设计接口，这样可以兼容信号已经被其他线程取走时候的便捷设计处理。

3. 从是否带有try的两个lock的对比可以看得出来，没有try的API，在信号已经被其他线程占用了的情况下会导致等待。而try接口则会跳过去。

4. 全部解锁的功能，在一个线程只拥有一个互斥信号的情况下执行效率更高，采用这种方式可以加速执行效率。

1. 条件变量本质上是一个线程队列，wait操作会释放上一次获取到的互斥信号，然后把当前的任务加入到条件变量队列中。

2. 条件变量信号发送或者广播执行的时候，会重新获取之前释放的互斥信号，之后从wait返回。

3. 1和2的动作其实是上面图中的2个可以来回跳转的状态。

1. 条件变量不能够单独使用，需要结合互斥信号。他的理解可以参考这个三间房的模型来理解。互斥信号的锁定可以作为一个触发信号来触发进入状态机的条件，进入所谓的“中庭”状态，这个状态其实是一个排队过程。形象一点理解，也就是说这个lock的动作，触发了一个中庭排队的动作。当请求互斥信号的时候，从中庭的排队成员中取出一个，进入到主房间。而这个主房间不是队列，是一个单个元素。此时，如果解锁互斥信号，那么整个状态就会结束。这也跟前面所说的，条件变量不能单独使用必须与互斥信号结合使用对的起来。到此为止，其实还没有涉及到条件变量，只是涉及到了互斥信号。如何涉及到条件变量呢？当互斥信号获取到之后，通过条件变量wait API来触发就可以来到这个条件变量队列中进行等待。这个条件变量的等待队列，是模型中的等待房间排队。等不及的时候，可以同等待房间退出。而chCondSignal API则会让“中庭”多一个等待人员。

2. 监控器的代码模板流程：先lock一个互斥信号，之后等待条件满足，最后释放互斥信号。

         针对上面的模型处理的内容，感觉上还是一个提供以及消耗的过程。提供方检查队列，如果队列不满就写，满了就等。而对于消耗方来说，如果队列不空就读，空了就等。在这里，互斥量可以保证信息的一致性。

         如果是涉及到中断，中断一般是作为一个提供方。不同线程可以等待阻塞，中断一般会直接跳过。不过，可能会有信息或者数据因此丢失。

         这就是互斥信号与条件变量的一个简单小结，其中互斥信号其实是容易理解的，这个条件变量理解的有一点费劲。或许，得看到一个实际的使用场景例程才能够更准确理解这个设计的意图。