I believe you are already familiar with the term task. But before explaining the different RTOS task states I want to give a small introduction of a Task. The term task is used in a variety of ways. It sometimes means a separately loadable program. There are two other terms that more or less replace the use of task and these are “process” and “thread”.
You have listened to these terms process and thread multiple times. Basically, a process is a completely independent program that has its own address space. But besides that, a thread is a semi-independent program segment that executes within a process and each process must have at least one thread.
In a multi-process model, each process has its own address space and cannot access the memory associated with other processes or the RTOS. It makes the context swap more complex and time-consuming, also we require to set up the memory management unit (MMU) appropriately.
Of course, the multi-process model is only possible with a processor that supports an MMU. Most embedded applications cannot afford the overhead (both memory and performance) associated with a full-blown process-oriented operating system. It is the reason most RTOSes used in embedded applications employ a multi-thread model. The threads share the same process address space. The overhead associated with thread management is minimal.
In this blog post, I will discuss the different execution states of the task. The execution state of the task is managed by the kernel. Here I am referring to the “free RTOS” task states.
Different states of a task in free RTOS:
In the FreeRTOS there are four distinct task states: Running, Ready, Blocked, and Suspended. Let’s see each state one by one.
Running:
When a task is actually executing it is said to be in the Running state. If the processor on which the RTOS is running only has a single core then there can only be one task in the Running state at any given time. This is because a task in the executing state has control of the underlying processor.
Ready:
A task is in a ready state when it is ready for execution (neither in the Blocked or Suspended state) but is not currently executing because a different task of equal or higher priority is already in the running state.
Note: A ready task is not executed until it is the highest priority task in the ready state. When this happens, the kernel executes the task and changes its state from Ready to Running.
Blocked:
A task in a blocked state is not eligible for scheduling. A task will go in a blocked state whenever it is waiting for an event to happen. The event can be completing a delay period or the availability of a resource. After the cause for the block is removed, the task is placed back in a ready state.
Suspended:
A task in a suspended state is not eligible for scheduling. The tasks only enter or exit the Suspended state when explicitly called the API vTaskSuspend() and xTaskResume() respectively. You can see the above-mentioned image.
Like the blocked state task, the Suspended task does not go in a ready state. We need to call xTaskResume() API to resume the task.
If you are a beginner and looking for a good Online Course on RTOS, it is my recommendation you can check the below-mentioned courses.
Note: It is also important to know that some commercial kernels, such as the ThreadX kernel, define other, more granular states. In ThreadX there are five distinct thread states: ready, suspended, executing, terminated, and completed.