Task starvation and priority inversion in FreeRTOS - Time & Space Complexity
When tasks share resources in FreeRTOS, some tasks may wait longer than others.
We want to understand how waiting time grows when tasks compete for resources.
Analyze the time complexity of this FreeRTOS snippet involving priority inversion.
// Task handles and mutex
SemaphoreHandle_t xMutex;
void vHighPriorityTask(void *pvParameters) {
xSemaphoreTake(xMutex, portMAX_DELAY); // Wait for mutex
// Critical section
xSemaphoreGive(xMutex);
vTaskDelay(10);
}
void vLowPriorityTask(void *pvParameters) {
xSemaphoreTake(xMutex, portMAX_DELAY); // Wait for mutex
// Critical section
vTaskDelay(50); // Simulate long work
xSemaphoreGive(xMutex);
}
This code shows a high priority task and a low priority task sharing a mutex.
Look for loops or repeated waits that cause delays.
- Primary operation: The high priority task waits repeatedly for the mutex held by the low priority task.
- How many times: Each time the high priority task runs and tries to take the mutex.
Imagine more tasks or longer critical sections increase waiting time.
| Input Size (n) | Approx. Operations |
|---|---|
| 1 (1 low priority task) | Low waiting time |
| 5 (multiple low priority tasks) | Waiting time grows as tasks hold mutex longer |
| 10+ | Waiting time can grow much longer due to priority inversion |
Pattern observation: Waiting time grows roughly with the number of lower priority tasks holding the resource.
Time Complexity: O(n)
This means waiting time grows linearly with the number of lower priority tasks blocking the resource.
[X] Wrong: "High priority tasks always run immediately without delay."
[OK] Correct: Because lower priority tasks holding resources can block high priority tasks, causing delays.
Understanding how task priorities affect waiting helps you design better multitasking systems.
"What if we use priority inheritance on the mutex? How would the time complexity change?"
Practice
task starvation mean in FreeRTOS?Solution
Step 1: Understand task scheduling in FreeRTOS
FreeRTOS schedules tasks based on priority, so higher priority tasks run more often.Step 2: Define task starvation
Task starvation happens when low priority tasks never get CPU time because higher priority tasks keep running.Final Answer:
Some tasks never get CPU time because others run too much -> Option AQuick Check:
Task starvation = some tasks starve for CPU [OK]
- Confusing starvation with equal CPU sharing
- Thinking tasks run randomly
- Assuming mutex controls CPU time directly
Solution
Step 1: Identify mutex creation functions
FreeRTOS usesxSemaphoreCreateMutex()to create mutexes with priority inheritance.Step 2: Differentiate other APIs
xQueueCreate()creates queues,vTaskDelay()delays tasks, andxTaskCreate()creates tasks, not mutexes.Final Answer:
xSemaphoreCreateMutex() -> Option BQuick Check:
Mutex with priority inheritance = xSemaphoreCreateMutex() [OK]
- Choosing xQueueCreate() for mutex
- Confusing task creation with mutex creation
- Using delay functions instead of mutex APIs
Solution
Step 1: Understand priority inversion scenario
Low priority task holds mutex needed by High priority task, so High task blocks waiting.Step 2: Effect without priority inheritance
Medium priority task runs, preventing Low task from running and releasing mutex, causing High task to wait indefinitely.Final Answer:
High task waits indefinitely while Medium task runs -> Option CQuick Check:
Priority inversion without inheritance = High task blocked [OK]
- Assuming low task releases mutex immediately
- Thinking high task preempts low task despite mutex
- Believing medium task is blocked
void lowTask(void *pvParameters) {
xSemaphoreTake(mutex, portMAX_DELAY);
// long processing
xSemaphoreGive(mutex);
vTaskDelete(NULL);
}
void highTask(void *pvParameters) {
xSemaphoreTake(mutex, portMAX_DELAY);
// quick processing
xSemaphoreGive(mutex);
vTaskDelete(NULL);
}Solution
Step 1: Analyze mutex usage in code
Both tasks take and give the mutex correctly, so no misuse in code logic.Step 2: Check for priority inversion cause
If mutex was created without priority inheritance, low task holding mutex blocks high task causing priority inversion.Final Answer:
Mutex created without priority inheritance support -> Option AQuick Check:
Priority inversion fix needs mutex with priority inheritance [OK]
- Assuming high task does not take mutex
- Thinking low task never releases mutex
- Believing tasks have same priority
Solution
Step 1: Understand causes of starvation and inversion
Starvation happens when low priority tasks never run; inversion when low priority blocks high priority.Step 2: Apply solutions in FreeRTOS
Using mutexes with priority inheritance prevents inversion; balanced priorities avoid starvation.Final Answer:
Use mutexes with priority inheritance and design balanced task priorities -> Option DQuick Check:
Priority inheritance + balanced priorities prevent issues [OK]
- Setting all tasks to same priority causing inefficiency
- Avoiding mutexes causing race conditions
- Using busy-wait wastes CPU and worsens starvation
Ready to prove it?
Pass the test and this pattern moves unknown
