STATES

RTOS Task States: RTOS Basic

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.

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.