vTaskSuspendAll in prvProcessTimerOrBlockTask

Kernel
1

The scheduler is suspended on entry to prvProcessTimerOrBlockTask. I don’t understand what it is intended to protect there. To my understanding, only the subroutine prvAddCurrentTaskToDelayedList called by vTaskPlaceOnEventListRestricted needs to be guarded by vTaskSuspendAll and xTaskResumeAll to protect the task lists (ready task list and delayed task list). Putting vTaskSuspendAll at the beginning of prvProcessTimerOrBlockTask looks like an overkill. Could anybody shed some light on this? Many thanks.

2

I think it is protecting against time changing within the function as it is dependent on time being consistent between sampling the time and checking if a timer has expired.

3

Thanks, Richard. I also thought about that reason. But if that’s the purpose of the vTaskSuspendAll there, shouldn’t it be taskENTER_CRITICAL instead, since interrupts can happen after the time is sampled as well, which can also lead to inconsistency between sampling the time and checking if a timer has expired?

4

Note here that when the scheduler is supended, ticks are handled differently.

So kernel time stands still when the scheduler is suspended, only to get all caught up when the scheduler resumes.

1 Like
5

One thing to note, FreeRTOS is very conservative in its use of taskENTER_CRITICAL, and only uses it if the possible duration is strictly bounded and short, because during the critical section ALL interrupts (that can interact with FreeRTOS) are blocked, so long critical section can cause issues with fast I/O. As I remember, prvProcessTimerOrBlockTask walks a list inside that section, so the time limit inside in not well bounded (the list could be long), so it isn’t advisable to use a critical section.

6

Thanks, @jefftenney, it makes more sense to me now.

7

Thanks, @richard-damon