1286_FreeRTOS的任务优先级设置实现分析

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.

前面简单分析了优先级的获取，实现上很简单。优先级的获取分为一般的OS API还有一个中断安全的版本。在具体的实现上没有太多的代码实现上难理解的地方，仅仅是一个属性的获取。这一次看看优先级的设置实现，不同于优先级的获取，设置其实只有一个接口。

首先保证设置的优先级数值是合理的，进而根据优先级允许的数目来计算实际的优先级。

接下来进入临界保护，获取需要修改优先级任务的当前的基础优先级。

待修改任务的当前基础优先级不等于需要修改的优先级的时候才有修改的需要，如果修改又会分为优先级提升和优先级降低两个可能。因为优先级的提升可能会高过当前正在运行的任务的优先级，这样的话就需要一个任务的切换。但是，高于当前正在运行的优先级又会有两种可能。要么是其他的任务要高于当前的任务，要么是当前任务本身需要提升优先级。针对后者，其实当前任务已经是最高优先级的就绪任务了，那么也就没有了 调度切换的需要了。

如果修改优先级的任务不是当前的任务，也需要调度的处理。这里设计倒是没有麻烦，最初我还以为会看看次最高就绪优先级，与之做一个对比。

暂时没有理解uxBasePriority属性的作用，但是从这部分预编译的信息来看，应该是为了支持互斥信号而实现的一种属性状态。

这部分主要是针对事件功能的支持，目前这个功能我还没有做测试以及分析。看起来，分析完整个FreeRTOS的实现还是需要花点事件的。

修改了任务的优先级之后，任务可能就不在之前的任务就绪链表中了。因此要有一个移除的处理，这里不需要担心设置相同优先级的情况，因为前面的分支部分已经直接跳过了这样的处理。待处理任务从之前优先级就绪任务链表中移除之后，如果移除之后的链表空了那么应该做一下reset。

后面这部分容易理解，如果需要进行任务调度的话做一个调度的请求。之后，退出临界保护。

相比优先级的获取来说，这个的确是多了一点复杂度。主要的差一点在于任务切换的处理，因为优先级的获取不涉及到任何优先级的变化也就不会破坏调度的判断依据。而优先级的设置则有比较大的偏差了，这个可能因为优先级的调整而触发任务调度。因此，多了一点复杂度。但是总体看来，也不是很难。看了很多功能实现分析，然后再考虑下实际的应用，其实在我现在的使用需求下OS应该是能够裁剪到更小的。

整个OS的机制现在理解下来不是很难理顺，但是并不等同于难度不大，毕竟难点可能都是隐藏于中断保护等细枝末节之中。如果全都考虑清楚了，可能还是需要花很多的功夫的。