RTOS Interview Questions: Scheduling, Priority Inversion, and Interrupts
Quick Overview
Practical RTOS interview preparation with task-state traces, fixed-priority scheduling, priority inversion, mutex inheritance, interrupt-safe design, and timing-focused debugging.
RTOS Interview Questions: Scheduling, Priority Inversion, and Interrupts
RTOS interviews rarely test vocabulary alone. A common prompt gives you three tasks, one mutex, and an event sequence, then asks what runs, what blocks, and whether a deadline is still achievable. The useful skill is tracing the state transition, not saying “the scheduler handles it.”
Start with the scheduling model
State your assumptions first: fixed or dynamic priorities, preemptive or cooperative scheduling, tick-based or event-driven wakeups, and whether equal-priority tasks time-slice. Then trace each task as Ready, Running, or Blocked. A higher-priority ready task usually preempts a lower-priority running task in a preemptive fixed-priority design, but exact behavior depends on the RTOS configuration.
When asked about a periodic task, separate period, deadline, execution time, and response time. A task can run periodically and still miss its deadline if interrupts, critical sections, or higher-priority work consume too much time. Explain what measurement or worst-case bound you would need before claiming the system is schedulable.
Priority inversion: trace ownership, not labels
Suppose low-priority task L holds a mutex. High-priority H becomes ready and blocks on that mutex. Medium-priority M is also ready. Without mitigation, M can preempt L repeatedly, so H waits indirectly for M even though M does not use the resource. That is priority inversion.
| Moment | State | What to say |
|---|---|---|
| L locks resource | L owns mutex | Record the owner before H arrives |
| H requests mutex | H blocks | Identify the blocking dependency |
| M becomes ready | M may preempt L | Explain the unbounded interference risk |
Priority inheritance can temporarily raise L while it owns the mutex, allowing it to finish the critical section and release the resource. It reduces this form of inversion but does not make every blocking path harmless. Keep critical sections short, avoid blocking calls while holding locks, and explain the RTOS’s actual mutex semantics rather than treating inheritance as a universal guarantee.
How should an interrupt handler be designed?
Keep the ISR bounded and predictable. Capture the minimum state, acknowledge or clear the hardware condition as required, and defer slower work to a task or work queue. Avoid lengthy parsing, allocation, blocking mutex calls, and unpredictable loops in interrupt context. If a shared data structure is touched by both an ISR and task, explain the synchronization primitive and its interrupt-safety guarantees.
Interviewers may ask about interrupt latency, nesting, priority masking, and what happens if an event arrives faster than the consumer can process it. A strong answer names the queue depth or overflow policy, not just the word “queue.”
Answer common RTOS questions with a trace
Why can a high-priority task miss its deadline? Check blocking time, interrupt interference, execution-time assumptions, priority assignment, and long critical sections.
Is a mutex safe in an ISR? Usually blocking mutex operations are not appropriate in an ISR; use the RTOS-approved ISR-safe signaling API and defer work.
How do you debug jitter? Timestamp release and completion, measure worst-case execution and interrupt latency, then correlate outliers with lock waits and competing tasks.
For adjacent scheduling and concurrency practice, browse PracHub’s systems and design interview questions.
Quick reference diagrams
Source: FreeRTOS mutex and priority-inheritance notes. The exact behavior varies by RTOS and configuration.
Three quick-reference diagrams
Task scheduling:
Priority inheritance:
Safe ISR workflow:
Comments (0)