1288_FreeRTOS中vTaskResume()接口以及中断安全版本接口实现分析

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)

近几次的接口分析分析的可能都是比较简单的项目，分析的时候都比较顺利。当然，也有可能是之前看的信息已经达到一定量了对现在理解这些接口有了一定的帮助。

这一次，再分析一个简单的接口vTaskResume()。

值得注意的是上面的预处理，其实是跟之前的挂起任务的接口的预处理是同一个条件。两个处理有一点逆向的意思，也很好理解为什么是同时存在。

其实，是否同时存在并不是很关键。对我来说比较有价值的信息是，这些功能在我之前接触的一些项目中其实是用不到的，因此做这方面的修改应该可以保证OS裁剪到更小的规格。

回到软件代码的设计分析本身，首先这里判断了即将恢复的任务是存在的。一般情况下，如果对于任务的处理句柄是NULL的时候通常是默认要处理当前的任务，但是这个操作在合理性分析上不成立。因此，这里增加了一个这样的检查断言。

后面的这部分代码实现其实是比较简单的，一个很重要的点是这个操作处理不该处理当前的任务。因为当前的任务肯定是在运行中的，如果要做这样的处理肯定是无意义的。因为，当前运行中的任务没有挂起的可能。另一个需要注意的点是被恢复的任务的优先级，因为优先级高的任务就绪可能会涉及到任务调度的处理。

关于真正需要恢复的任务处理，首先得讲任务从挂起链表中移除，之后将其加入到就绪任务链表。增加了之后，判断一下恢复任务的优先级，跟当前的任务优先级做一个比较之后可以知道接下来是否需要任务调度的请求处理。最后处理这个任务调度请求即可。

中断安全版本的与普通API的处理差异主要在于2点。第一，中断安全版本的屏蔽了OS托管的中断ISR，防止干扰发生。另外一点，中断中处理任务的挂起其实就不需要考虑调度器是否挂起，其实都是可以挂起的，甚至是当前的task。因此，传入的任务句柄只是看了一下是否是有效的，并没有判断是否是正在处理中的任务。而针对调度器的挂起，有一个额外的链表做临时缓冲，当调度器恢复后把任务转移到就绪任务链表。