3Real-time OS & task management
- 3.1The role of an RTOS and task state transitions
Covers what an RTOS (real-time operating system) is designed to prioritize over a general-purpose OS, the kernel's role in task management, scheduling, and interrupt handling, the three-state transition of a task between running, ready, and waiting (including dormant), and how to judge whether an embedded project should adopt an RTOS or can rely on bare-metal (no-RTOS) design.
- 3.2Scheduling
Covers the difference between priority-based scheduling and round-robin, the rate-monotonic (RM) fixed-priority algorithm and its utilization-bound schedulability test (the Liu & Layland bound), the Earliest Deadline First (EDF) dynamic-priority algorithm, and how the presence or absence of preemption affects responsiveness—together with judging whether a real periodic task set can meet its deadlines.
- 3.3Inter-task synchronization and communication
Covers the difference in purpose between a semaphore and a mutex for mutual exclusion (counting resource management versus exclusive ownership), event flags for signaling that an event occurred, and the difference between a mailbox and a message queue for passing data—together with judging which primitive to choose for a given inter-task coordination scenario.
- 3.4Priority inversion and deadlock
Covers the mechanism by which priority inversion arises (a high-priority task is blocked waiting for a resource held by a low-priority task, and is further delayed indefinitely by a medium-priority task preempting that low-priority task), the difference between the two remedies—priority inheritance and priority ceiling—and the four conditions for deadlock (including circular wait) along with avoidance strategies.
- 3.5Interrupts and real-time behavior
Covers the design of separating the ISR (interrupt service routine) from a task and delegating time-consuming work to deferred processing, the difference between hard real-time and soft real-time, the factors behind interrupt latency and jitter, and how response-time analysis is used to estimate worst-case response time.

