Tasks, Context Switching, and Scheduling

An RTOS lets you write each activity as a task: an ordinary C function, usually an endless loop, with its own stack and a priority. Because each task has its own stack, it can be stopped anywhere, in the middle of a function call chain, and resumed later with every local variable intact. That is what protothreads (lesson 2) cannot do.

void sampler(void *arg) {                        /* a FreeRTOS task */
    TickType_t last = xTaskGetTickCount();
    for (;;) {
        read_sensor();
        xTaskDelayUntil(&last, pdMS_TO_TICKS(2));  /* previous wake time + 2 ms (configTICK_RATE_HZ = 1000) */
    }
}

At any moment each task is in one state. FreeRTOS names them running (on the CPU; one per core), ready (could run, waiting for the CPU), blocked (waiting for time to pass or for an event: a queue, a semaphore, a notification) and suspended (taken out of scheduling explicitly). A blocked task uses no CPU time at all. When nothing is ready, the RTOS runs its idle task, at priority 0, where the CPU can sleep.

The scheduler’s rule is short: the highest-priority ready task runs. It is applied whenever something changes, which Zephyr calls reschedule points: a task blocks, a task becomes ready (a semaphore is given, a delay expires on a tick), or an interrupt handler returns after making a task ready. If a task more urgent than the running one becomes ready, the running task is preempted at once, in the middle of whatever it was doing.

↑ This step uses the figure at the top of the page.

Priority numbering is not portable: in FreeRTOS a higher number is more urgent (the idle task is 0), in Zephyr a lower number is more urgent and negative numbers are cooperative threads, and in the NVIC a lower number is more urgent (unit 9, lesson 3). Interrupts still preempt every task, whatever its priority, unless they are masked.

Choosing priorities. For periodic tasks with deadlines at the end of their periods, a good and simple rule is rate monotonic: the shorter the period, the higher the priority. It is not about importance: a critical task with a long period can safely run at a low priority if the analysis (lesson 6) shows it still meets its deadline, and a short, frequent task at a low priority can miss its deadlines while longer tasks run.

Tasks of the same priority do not preempt each other. With preemption on and time slicing enabled (FreeRTOS configUSE_TIME_SLICING, which defaults to 1), the tick interrupt requests a switch whenever another task of the running task’s priority is ready, so equal-priority tasks take turns, one tick each. Zephyr can do the same for preemptible threads with a configurable slice. Time slicing shares the CPU among equals; it does nothing for latency between different priorities.

Three tasks have deadlines equal to their periods: A needs 1 ms every 5 ms, B 3 ms every 10 ms, C 6 ms every 20 ms. The load is

Preemptive, rate monotonic (A highest): A runs 0–1, B 1–4, C 4–5. A is released at 5 and preempts C: A 5–6, C 6–10 (5 ms done). At 10, A and B are released: A 10–11, B 11–14, then C’s last millisecond 14–15. Worst responses: A 1 ms, B 4 ms, C 15 ms, all within their periods. Cooperatively, C starts at 4 and keeps the CPU until 10: A, released at 5, starts at 10 and finishes at 11, a response of 6 ms, past its 5 ms deadline. With reversed priorities (C highest), A waits behind C and B even with preemption: A finishes at 10.

The cost of preemption is one context switch per preemption and three stacks instead of one: at least 68 bytes of saved context for each suspended task, plus each task’s own deepest call chain and a margin.