Task Management

Every task running on an RTOS must be tracked, controlled, and transitioned between different execution states. The RTOS kernel manages each task using a data structure called the Task Control Block (TCB), and every task follows a well-defined lifecycle through states such as Ready, Running, and Blocked. Understanding task management is essential for writing correct real-time software and for GATE Embedded Systems questions.

Core Concept Explanation

When an RTOS creates a task, it allocates a TCB and a private stack for that task. The TCB is essentially a snapshot of the task at any point in time. It stores the task ID, current state, priority, stack pointer, program counter, and all CPU register values. When the scheduler switches from one task to another, it saves the current CPU context into the current task's TCB and loads the context from the next task's TCB. This process is called a context switch and it is the fundamental mechanism behind multitasking.

A task can exist in several states. In the Ready state, the task is fully prepared to execute and is waiting in the scheduler's ready queue. In the Running state, the task currently holds the CPU. Only one task can be in the Running state at any given time on a single-core processor. In the Blocked state (also called Waiting), the task is waiting for a resource, event, semaphore, or delay to expire. A Blocked task does not consume CPU time.

Some RTOS implementations also include a Suspended state, where a task is explicitly halted by another task or by the task itself. Unlike Blocked, a Suspended task cannot be automatically unblocked by an event. It must be explicitly resumed. In FreeRTOS, the functions vTaskSuspend() and vTaskResume() manage this state transition.

Mathematical Expression

Context switch overhead is a critical metric in RTOS performance evaluation. The total CPU time consumed by context switching can be estimated as follows. If a context switch takes Tcs microseconds and N context switches occur per second, the overhead is N times Tcs microseconds per second. The effective CPU availability for application tasks is then reduced by this overhead. For example, if a context switch takes 2 microseconds and the tick rate is 1000 Hz with 5 tasks switching at every tick, the overhead can be significant.

The stack memory required for all tasks is: Total Stack = sum of individual task stack sizes. Each task's stack must be large enough to hold its deepest function call chain plus the saved CPU context (which is a fixed overhead per architecture, typically 16 to 32 registers, each 4 bytes on a 32-bit CPU).

Practical Understanding

In FreeRTOS, tasks are created using xTaskCreate(). The developer specifies the task function, priority, stack depth, and a parameter pointer. FreeRTOS allocates the TCB and stack dynamically from the heap. The scheduler automatically manages state transitions. Stack overflow is a common bug in RTOS development: if a task's stack grows beyond its allocated size, it corrupts adjacent memory. FreeRTOS provides configCHECK_FOR_STACK_OVERFLOW to detect this.

Priority assignment is critical. In a system where a sensor reading task must complete within 1ms, it must be assigned higher priority than a display update task that can tolerate 100ms delays. Poor priority assignment is one of the most common causes of timing failures in RTOS-based embedded systems.

Given:
Task A: Stack depth = 128 words (4 bytes each), Priority = 2
Task B: Stack depth = 256 words (4 bytes each), Priority = 1
Context switch overhead per switch = 1.5 microseconds
Tick rate = 1000 Hz, assume 2 context switches per tick

Why this formula applies:
Total stack usage determines RAM allocation.
Context switch overhead determines CPU efficiency.

Formula:
Total Stack RAM = (128 + 256) words x 4 bytes/word
CPU overhead per second = 2 switches/tick x 1000 ticks/sec x 1.5 us/switch

Substitution:
Total Stack RAM = 384 x 4 = 1536 bytes
CPU overhead = 2000 x 1.5 us = 3000 us = 3 ms/sec

Calculation:
Total Stack RAM = 1536 bytes = 1.5 KB
Overhead = 3 ms out of 1000 ms = 0.3% CPU

Final Answer:
Stack RAM needed = 1.5 KB; Context switch overhead = 0.3% CPU per second.

Exam Tip: In GATE questions on RTOS task states, remember that a Blocked task does NOT consume CPU time but remains in memory. A Suspended task requires explicit resume. Only one task can be in Running state on a single-core processor at any instant.

Mechanism - Task State Transitions

• When a task is created, it enters the Ready state and is placed in the ready queue sorted by priority.
• The scheduler picks the highest-priority Ready task and dispatches it to the Running state by performing a context switch.
• If the Running task calls a blocking API (wait for semaphore, delay, I/O wait), it moves to Blocked state and the scheduler picks the next Ready task.
• When the event a Blocked task is waiting for occurs (semaphore posted, delay expired), the kernel moves it back to Ready state.
• A higher-priority task becoming Ready causes immediate preemption of the currently Running task in a preemptive RTOS.

Quick Revision

• TCB stores: Task ID, state, priority, stack pointer, program counter, register context, timeout counter.
• Task states: Ready (in ready queue), Running (on CPU), Blocked (waiting for event), Suspended (explicitly halted).
• Only ONE task can be in Running state on a single-core RTOS at any time.
• Context switch: save current task CPU registers to TCB, load next task registers from its TCB.
• Total stack RAM = sum of all task stack sizes. Always allocate slightly more than minimum to avoid overflow.
• Exam trap: A Blocked task does NOT waste CPU cycles. It is removed from the ready queue entirely until its event occurs.