Operating System Basics

Computer Organization & Embedded System — Real-Time Operating and Control System, NEC licence examination syllabus (Nepal Engineering Council).

Operating System Basics: what an RTOS actually promises

A regular OS promises fairness. A real-time OS promises deadlines.

The kernel is the core of the OS, running in a privileged mode with full hardware access; everything else (your apps) runs in user space, restricted for safety. Common OS services: process management, memory management, file systems, and I/O handling.

⏱️ RTOS vs GPOS

GPOSA General-Purpose OS (like Windows) optimizes for average throughput and fairness.

RTOSOptimizes for predictability — guaranteeing a task finishes within its deadline, even if that means being less "fair" overall. Real example: the RTOS in a car's anti-lock brake system.

Hard real-time: missing a deadline = system failure (e.g., anti-lock brakes). Soft real-time: missing a deadline degrades quality but doesn't cause failure (e.g., video playback stutter).

💡 One-liner trap: RTOS doesn't mean "fast" — it means "predictable/deterministic." A slow RTOS that always meets its deadline is more "real-time" than a fast GPOS that sometimes misses one.

Hard and soft real-time

"Guaranteeing a task finishes within its deadline" covers two quite different promises, and questions turn on which one applies.

⏰ What a missed deadline costs

Hard real-timeA missed deadline is a system failure. An airbag controller, a pacemaker, an engine management unit — a late result is not a degraded result, it is a wrong one.

Soft real-timeA missed deadline degrades quality but the system remains correct. A dropped video frame or a stutter in audio is undesirable, not catastrophic.

Firm real-timeA late result is useless but harmless — discard it. A stale sensor reading in a display, for instance.

The distinction decides the entire design. A hard real-time system must be provable in the worst case, so every path is bounded and unpredictable features are excluded outright. A soft one can be tuned for the common case and allowed to occasionally miss.

A real-time system is not a fast system

This is the point candidates most often get wrong, and it is worth stating bluntly.

An RTOS frequently has worse average throughput than a general-purpose OS, and accepts that deliberately. The goal is not speed but predictability — a system that always responds in 10 ms is real-time, while one that usually responds in 1 ms and occasionally takes 50 ms is not, however much faster it is on average.

💡 So "make it real-time" does not mean "make it faster". It means bounding the worst case, which often costs average performance — and a question asking whether a faster processor makes a system real-time is testing exactly this. It does not; it makes an unpredictable system unpredictably faster.

What an RTOS gives up to get the bound

🚫 Features that destroy predictability

Demand pagingA page fault costs a disk access at an unpredictable moment, so real-time memory is usually locked in RAM.

Fair schedulingFairness means a low-priority task can delay a high-priority one. An RTOS uses strict priority and preempts immediately.

Unbounded queuesAnything that can grow without limit can delay without limit.

Long critical sectionsEvery region with interrupts disabled adds to worst-case latency — see the Device Drivers topic.

💡 Priority inversion is the classic failure this creates: a high-priority task waits on a lock held by a low-priority one, which is itself preempted by a medium-priority task — so the highest-priority task is blocked by a task it outranks. The fix is priority inheritance, where the lock holder temporarily takes the priority of whoever is waiting. It is a favourite exam question because the mechanism is subtle and the consequence is a missed deadline in a system that looked correct.

Syllabus points

Kernel, user space, OS services
RTOS vs GPOS; hard vs soft real-time

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.