Which API functions are available for use when scheduler is suspended using vTaskSuspendAll?

Kernel
#1

I want to use xTaskGetTickCount after calling vTaskSuspendAll when the scheduler is OFF. The documentation for vTaskSuspendAll function restricts calling of freertos API functions when the scheduler is suspended. But the xTaskGetTickCount function is simple and must be allowed for use.

Can someone help me know the API functions that are allowed to be used while the scheduler is OFF . . .

I want to make use of xTaskGetTickCount after calling vTaskSuspendAll.

Thank you :slight_smile:

#2

It is too complex to list out the functions that can and can’t be used when the scheduler is suspended or from within a critical section - so there is a general rule of thumb that says don’t do it. The thing to really avoid is anything that could cause the calling task to block, that is always bad because if the scheduler is locked or the context switch interrupt’s can’t execute you will get a logic error - i.e. the calling task will continue running when it should be blocked waiting for an event. The next category of things to watch out for, but are less critical, is any function that unblocks another task - for similar reasons - although the errors you see will not necessarily be fatal as in the first case. In the case of xTaskGetTickCount(), the code is not doing anything other than returning a value, so it is ok to call with the scheduler suspended:
https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/V10.4.3/tasks.c#L2328

#3

Thanks for the answer @rtel
I’ll now be able to use of the xTaskGetTickCount function in the critical region.

Could you help me know if a function that unblocks other tasks is successful in marking it as unblocked in a crtical region? And whether the task will try to run only after the scheduler is resumed.

#4

It might be easier to know what else do you plan to do in a critical section.
Usually the code in critical sections is kept as short as possible and is used to protected access to shared data.

1 Like
#5

That is correct - the unblocked task will run when the next time scheduler runs. As @hs2 mentioned, knowing what you are trying to achieve may be useful to decide if you really need to unblock a task when the scheduler is suspended.

Thanks.

1 Like
#6

A task that is unblocked when the scheduler is locked will start to run immediately the scheduler is unlocked - before the xTaskResumeAll() function returns. Assuming it has a priority above the currently running task of course.

Whether a task that is unblocked in a critical region executes immediately that the critical region is exited depends on the RTOS port. Ports that use asynchronous mechanism such as the Renesas RX or ARM Cortex port signal the requirement of a context switch by pending an interrupt - the handler for which will execute as soon as you leave the critical section. Ports that use a synchronous method, such as the ARM7 and ARM9 ports (not to be confused with the Cortex-M port which as an ARMv7M architecture) will not start to run the unblocked task until the scheduler runs again - worst case will be when the tick interrupt next executes.

1 Like