Question 3 of 6: RTOS Features, Rationale, and Real-Time vs. Non-Real-Time Systems

Question 3: RTOS Features, Rationale, and Real-Time vs. Non-Real-Time Systems (20%)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) Typical features of an RTOS. A real-time operating system is distinguished from a general-purpose OS by a small set of properties that all serve predictability rather than average-case throughput: (i) a deterministic, priority-based preemptive scheduler (fixed-priority such as Rate-Monotonic, or dynamic-priority such as EDF) with bounded, analyzable worst-case scheduling latency; (ii) bounded interrupt-latency and bounded, short interrupt-service-routine execution; (iii) priority inheritance or priority-ceiling protocols to bound priority inversion when tasks share resources via mutexes; (iv) a small, deterministic kernel footprint with system calls that execute in bounded time (no unbounded-latency operations such as unrestricted disk paging in the critical path); (v) precise, high-resolution clock and timer services for periodic task release; and (vi) predictable, minimal memory management (often static allocation or a fixed-latency allocator, avoiding a general-purpose garbage collector's unpredictable pause times).

(b) Why RTOSs are used in real-time applications. A real-time application's correctness depends on meeting deadlines, not merely on eventually producing the right answer; a general-purpose OS optimizes for average throughput and fairness, which can let a low-priority-looking-but-urgent task be starved by scheduling policies, page-fault stalls, or unbounded system-call latency. An RTOS is used specifically because it provides the analyzability needed to prove, before deployment, that every task's worst-case response time is within its deadline (schedulability analysis) — something a general-purpose scheduler's best-effort, throughput-oriented policies cannot guarantee.

(c) Hard vs. soft real-time systems — careful definitions. A hard real-time system is one in which every task has a deadline whose violation constitutes a system failure — the correctness of the system is defined jointly by logical correctness and timeliness, and a late (even if logically correct) result is treated as a wrong result; hard-real-time designs therefore require a schedulability guarantee for the absolute worst case, not merely the common case. A soft real-time system is one in which deadlines express a desired quality of service rather than a correctness requirement: a late result retains partial value that degrades (often continuously) with lateness, and occasional missed deadlines are tolerated as a quality trade-off rather than treated as failures — schedulability is typically analyzed statistically (e.g. bounding the fraction of missed deadlines) rather than for the absolute worst case.

(d) Fundamental differences between real-time and non-real-time systems.