1333_FreeRTOS中xQueueSemaphoreTake函数的实现分析

全部学习汇总： https://github.com/GreyZhang/g_FreeRTOS

这次看一下xQueueSemaphoreTake函数的实现，结合之前队列接收的分析，其实这个是很容易懂的。整个处理机制其实是差不多的，但是这里面少了数据搬运的动作。

进行信号的提取动作的时候，调度器不能是挂起的。

接下来，又是一个死循环的结构，其实处理的一些机制又是有任务的处理理念了。但是，这个不同于任务的定义，这个处理是有退出返回的可能性的。处理首先得看被提取的队列中有没有元素，有的话提取，没有的话还得去看是否有等待时间的设置。这样的处理方式，通过队列的处理其实都是可以猜测出来的。如果队列中已经有了数据（确切说是信号不是数据信息），那么接下来信号的计数值减1。

队列的空间减少了一个，接下来的话就得去看看有没有激活的任务了。这样的操作跟队列传递的处理还是很相似的，只是少了数据的处理。

如果信号队列中没有信号存储，那么接下来还得看有没有等待处理的时间。如果没有，这次的处理也就结束了，接下来直接返回队列为空即可。如果需要等待，那么这样的返回信息即使是成立也得有一个延迟的时间，这个在后面的代码逻辑中是可以看得到的。

接下来的处理是等待超时的过程，如果等的过程中队列不再空，那么应该是直接提取信号即可，否则的话等到超时返回为空。我们分析的话会有这样的思路，实际上也是如此。但是，需要注意的是如果需要继续等待，这里其实是处理了等待任务，让其加入到了等待事件链表。

这里虽然不进行切换，但是其实在后面的调度器工作的时候会把这个“任务”切换回来，从而在前面的处理过程中提取到信号。

超时的很多处理在常规队列处理的时候做了一些防御式的编程，其实这个处理也是差不多的。从某些角度思考，其实我觉得直接返回队列为空的返回码就是可以的。

如果没有任何FreeRTOS设计的概念理解作为前提，可能类似的设计分析还是有些难的。但是现在整个工程看到现在，似乎越来越觉得这个OS的设计细节虽然复杂但是整体的框架还是很清晰的。