Cooperative Scheduling and Superloops

Unit 7, lesson 6 built a superloop: every pass calls every task, and each task checks the time itself. Its worst-case latency is one whole pass, the sum of all the tasks. A cooperative scheduler organises the same idea around a table:

typedef struct { void (*run)(void); uint32_t period, left; volatile bool due; } task_t;
static task_t tasks[] = {                        /* most urgent first; periods in ticks of 1 ms */
    { sample_sensor,   2, 1 },
    { control_loop,   10, 1 },
    { update_display, 20, 1 },
};
void tick_1ms(void) {                            /* timer interrupt: only marks tasks due */
    for (size_t i = 0; i < N_TASKS; i++)
        if (--tasks[i].left == 0) {
            tasks[i].left = tasks[i].period;
            if (tasks[i].due) overruns++;        /* still due from last time: one run is lost */
            tasks[i].due = true;
        }
}
int main(void) {
    for (;;) {
        bool ran = false;
        for (size_t i = 0; i < N_TASKS && !ran; i++)
            if (tasks[i].due) { tasks[i].due = false; tasks[i].run(); ran = true; }
        if (!ran) __WFI();                       /* nothing due: sleep until the next interrupt */
    }
}

The interrupt stays tiny (unit 9, lesson 6): it only counts down and sets flags. The loop runs the most urgent due task to completion, then scans again from the top, so a more urgent task that became due meanwhile goes next. On the pico-sdk the tick can be a repeating timer, whose callback runs from an IRQ handler. Each due flag is a single aligned variable, set by the interrupt and cleared by the loop (unit 9, lesson 5). If a task is still due when its next period starts, setting the flag again loses one run, so the tick counts it as an overrun. (A tick that lands between the scan and __WFI() is not lost: its flag is set, and the loop sees it after the next interrupt wakes it, at most one tick later. The standard way to avoid even that delay is to mask interrupts with __disable_irq(), scan, execute __WFI(), which still wakes on a pending interrupt, then __enable_irq().)

“Cooperative” means that tasks give the CPU back voluntarily, by returning. The scheduler cannot take it from them. A task that becomes due waits for whatever is running to finish, however unimportant that is. For the most urgent task, the worst start delay is therefore the longest single run of any other task:

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

Priorities decide who goes next, not who may interrupt. Zephyr describes its cooperative threads the same way: once running, such a thread “remains the current thread until it performs an action that makes it unready”, so lengthy computation delays even threads of higher priority. FreeRTOS has a cooperative mode too (configUSE_PREEMPTION set to 0), in which waking a more urgent task does not cause a switch; the switch happens when the running task blocks or yields.

The fix is the one from lesson 1: split long work into steps that each return quickly. A display task that redraws a few rows per call and keeps its position in a static variable is a state machine with one state per chunk. Protothreads (from the Contiki operating system) let you write the same thing as straight-line code: PT_WAIT_UNTIL(pt, condition) records the current line in a variable and returns from the function while the condition is false; the next call jumps back to that line with a switch. Two consequences follow directly from that implementation: local variables on the stack do not survive a wait (keep them in a structure or static), and a wait must not sit inside another switch statement.

Cooperative scheduling works when every task can be written with short runs. It fails when one job cannot be split (a library call that takes 30 ms, a flash erase that blocks the bus), when the shortest deadline is shorter than the longest unavoidable run, or when the code grows and every new function silently becomes part of every other task’s latency. Preemption (lesson 3) removes the dependency: an urgent task no longer waits for a long one to return, at the cost of stacks per task and shared data that needs protection.

The sample task (0.2 ms) is due every 2 ms, control (1 ms) every 10 ms, and the display update takes 8 ms every 20 ms. At t = 0 all three are due: sample runs 0–0.2 ms, control 0.2–1.2 ms, then the display 1.2–9.2 ms. The sample task becomes due again at 2 ms but cannot start until the display returns at 9.2 ms, 7.2 ms late. Meanwhile its flag is set again at 4, 6 and 8 ms: three of the ten samples in each 20 ms cycle are lost.

Rewrite the display to do 1 ms of drawing per call. Now the longest run of any task is 1 ms (the control loop, or one display step), so the sample task waits at most

In this schedule it never waits more than 0.8 ms, and no sample is lost. The display still finishes within its 20 ms period: its total work is unchanged, only interleaved.