What happens with a task when it's done before the tick time ends?

Hello everyone,

I’m new to this forum so I hope I’m posting this in the right category :slight_smile: .

I was thinking some steps through for my project (running on an ESP32) and I have a very short task that sometimes could be 1 if-statement and sometimes can take a few ms to run. Now the scheduler let’s task run for 1 tick (1ms) and then it will move on to the next scheduled task.
But I wonder what happens if the task is done running before the tick ends? Will it just idle your CPU for the rest of that tick? And if so, how should I properly implement it so I’m not wasting most of my CPU power waiting in a task?
Also, since all tasks run in an infinite while loop, the task will never be considered ‘done’, correct? So I guess if it doesn’t halt the CPU it will just run the if-statement one whole tick?

Thanks for any help.

Hi Thegainman,

intersting question, but a fairly pointless one. Creating and cleaning up tasks is a fairly costly process, so there’s no point in going through that for that little work. You might reconsider your design, eg keep a thread pool that gets signalled whenever one of your short computations is ready to continue (sort of like I/O completion ports).

Usually part of the mentioned forever loop is waiting for an event to do something. And waiting means to give up the CPU (done interanlly by the FreeRTOS scheduler). Sometimes for simple periodic tasks waiting (for an event) is done by a simple delay.
As RAc mentioned creating and deleteting tasks dynamically is often not a good idea especially with regard to resource constrained embedded systems.

I’m not sure whether I understood you correctly RAc. I have a task with 1 if-statement, and if that one becomes true it needs to do quite some calculations. If I’m correct when the task gets called it will just loop through the if-statement a whole 1ms (it will be most likely false). So you’re saying just only call the task when that if-statement is true?

it is also common that the OS runs an internal clock at a higher speed than the in my opinion, the RT kernel had to choose at each end of tick what to do for in the next thread only getting 5% of a time slice before the timer ticks again.

Hi Thegainmen,

we need to first get in sync with our understanding of things.

A task does not “get called,” it’s not a function. I initially read your post to mean that you create a task to do a (potentially) one cycle computation and then terminates itself. Is that how you meant it, or do you use the task more in its intended sense (eg sit in an infinite loop in which it either gets woken up or polls something and then runs through the (potential) one cycle loop?

Can we see some (pseudo) code of what you are doing?

First point, A task should NOT just “loop” on an if statement waiting for an expression become true and then do something. Such a task will starve any task of a lower priority.

A task should have a loop, and in that loop it should ‘block’ for a condition, and then do something, and go back to block until it has something to do.

This block could be a simple Delay call, or a read from a Queue or take a Semaphore, or wait for a Notification, etc. This is the key, while it is block, the RTOS knows that it doesn’t need time now, so give it to other tasks, and then when that condition comes, as long as no higher priority task is running, will run this task.