What happens when a task takes too long to run?

Kernel
1

I’m just trying to understand what happens when a task takes too long to run.

I have a time consuming function, which is called by a task within the scheduler. If the function takes too long to run, the task seems to be stuck, but the Task State (gotten from vTaskGetInfo as xTaskDetails.eCurrentState) is still 1, which according to RTOS task (thread) utilities including API functions for tracing FreeRTOS, getting the RTOS tick count, getting a task handle, getting the RTOS kernel or RTOS scheduler state, listing the tasks in the embedded system, and obtaining run time task statistics. is still Running, even though the execution of the task is halted. Is there any way of programmatically figuring out if the task has been halted?

2

FreeRTOS is not a time separated OS so doesn’t have a concept of a task taking too long to run.

A couple of comments on this. First if you are able to call vTaskGetInfo() from a different task then the task you call vTaskGetInfo() from is the task that is running, so the task in question is not running. Second is a value of 1 is not Running, but Ready (https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/V10.4.3/include/task.h#L90). Ready means the task is still able to run (it is not blocked) but is not running because a task of equal or higher priority is running - in this case presumably the task that is calling vTaskGetInfo().

So when the subject task is the highest priority task that is in the Ready state, and assuming no other tasks of equal priority, it will start to run again. I would recommend breaking in the debugger at that time to see what the task is executing. Maybe it has got into an infinite loop, or hit an assert, or something else.

3

Hi Richard,

Thanks for the info.

As of now, I have 2 tasks, one doing some computation at a high priority, and a second one that is only checking the status of the first one (and runs at the same priority). At some point, the first task stops executing, and does not resume. I am trying to figure out what exactly happens when that is the case, since the vTaskGetInfo on the first task of high priority is returning 1, yet the execution does not resume - which I would expect that at some point should happen, no matter how long I wait).

Are any of my assumptions mentioned above wrong? If not, any ideas where I can start looking?

Thanks!

4

No your assumptions are not wrong. Question would be, how are you assessing the task is not running, as the evidence you have posted so far shows that it is in the Ready state, so it will run when it is the highest priority task. As per my last post:

5

Thanks for the info. Looking at the code under gdb, I realized that the thread is getting a SIGALRM, and after that the execution is halted, never to be resumed.

Do I need to handle the signals being sent to the thread, or is the kernel supposed to do that for me? I can’t seem to find any documentation on this, if you could point me in the right direction, that would be appreciated.

6

Which port are you using? If you get a signal like that I could only assume the Linux port. If so, did you see the documentation for that port on FreeRTOS.org?