Two tasks that each print a message in an endless loop are created on one core. What happens when they have the same priority, and what changes when one has a higher priority?
Same priority: the scheduler time-slices, switching between them on every tick, so the messages interleave. Different priorities and no delay: the higher task never gives up the CPU, so the lower one never runs (starvation). Adding vTaskDelay(1000 ms) makes the high task block after each message, and the low task runs in that gap.
* Three cases on one core: time slicing at equal priority, starvation without a delay, and blocking with a delay. *
FreeRTOS's rule is always "run the highest-priority task that is Ready". The three cases follow from it:
- Equal priority. Both tasks are always ready and equally important. With time slicing (on by default), the tick interrupt every 10 ms hands the CPU to the other one, so "Hello from Task A" and "Hello from Task B" alternate in bursts.
- Higher priority, no delay. Task A is always ready and always outranks B, so B stays Ready forever and never runs. The idle task, at the lowest priority, also never runs, and ESP-IDF's task watchdog notices this and prints a warning after a few seconds.
- With
vTaskDelay(1000 / portTICK_PERIOD_MS). After printing, A moves to the Blocked state for 1000 ms. A blocked task is not a candidate, so B gets the CPU, prints and blocks too, and the idle task runs until A's timeout expires.
This is why the exercise asks for a delay only when the priorities differ: a higher-priority task has to block regularly, or every task below it starves.
Tip: priority decides who runs; blocking is the only thing that lets anyone else run.
Go deeper:
FreeRTOS — Task scheduling — fixed-priority preemptive scheduling with time slicing, and how starvation happens.- Wikipedia — Fixed-priority pre-emptive scheduling — the scheduling policy FreeRTOS uses, and its starvation risk.
- Wikipedia — Resource starvation — starvation in general, and the ageing technique some schedulers use against it.