1278_FreeRTOS_借助prvAddCurrentTaskToDelayedList接口理解delayed task

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

prvAddCurrentTaskToDelayedList()是上次分析vTaskDelay()的时候遗留的一个接口，这一次把这个接口简单分析一下。简单梳理了一下，发现这个接口其实解答了我之前对于delayed task 链表的一些疑惑。

把当前的任务加入到延迟处理的链表之中，也就意味着当前的任务需要从就绪任务链表中移除。但是，移除当然任务可能会导致当前任务所属的优先级就绪任务链表为空，那么就得复位相应的优先级就绪状态位。

如果延时时间是一个极大值或者是允许无限阻塞，那么直接把任务挂起。我觉得这个处理是不是欠缺一点“细腻”？如果就是想延时一个极大值，这个地方就实现不了了。

如果是有限的延时，那么进入到正常的处理流程。首先，设置当前任务的一个唤醒时间。这个时间其实是一个单位为tick的时间标度在未来的一个数值。因此，可能有超出最大数值的情况。如果这种情况，数据会回滚，可以通过将唤醒时间与当前的tick值做对比来判断是否有这种情况出现。如果出现，那么在当前的delayed task中继续处理就不合适了，需要在溢出的delayed task中处理。这就是之前看到的链表信息出现了两次的原因。如果没有溢出，在正常的链表处理，如果溢出则在溢出链表处理。当然，从这个角度看其实一般的配置下，溢出链表使用频率可能不大，或者说里面有任务的时候不多。这里还有一个点，那就是xNextTaskUnblockTime。这其实是delayed task所有的任务第一个将被唤醒的task。这样，有一个模糊的概念也清晰了。

后面这部分在我目前的配置中没生效，暂且不做分析，后面我会尝试各种不同的配置，到时候针对不同的配置再做相关部分的解读。