Foundations — OS roles — resource management, hardware abstraction, protection

Before you can read the parent note OS Roles fluently, you need a small toolbox of words, pictures, and one probability formula. This page builds every single one from nothing, in an order where each item leans only on the ones before it. If a word below already feels obvious, good — read it anyway, because the parent note stacks these into arguments and a shaky floor cracks the whole tower.

0. The two physical things we start from

Everything in this chapter is a story about two nouns: the hardware and the program. Let's nail down exactly what each is with a picture before any fancy word appears.

Look at the figure: along the bottom sits one box labelled HARDWARE — the single physical machine, split into its parts (CPU, RAM, Disk, I/O). Floating above it are several separate process boxes (P1, P2, …), and every one of them points an arrow down at the same machine. That downward crowd of arrows onto a single box is the whole tension of this chapter drawn in one picture: many demanders, one supplier.

Why does the topic need this distinction? Because "share the machine" really means "let many processes (running things) use one set of hardware (physical things)." The whole tension lives in the gap between one hardware and many processes. You will meet processes again in depth in Processes and Threads.

1. The CPU, a core, an instruction, and "one at a time"

The single most important physical fact in the whole chapter:

Look at the figure: real time flows left to right, and at every vertical slice exactly one colored process is on the core. The illusion of "all at once" comes from the slices being tiny (about 10 milliseconds — a hundredth of a second). This slicing is CPU Scheduling.

2. Time-multiplexing vs space-multiplexing

The parent note says the OS "multiplexes" resources in two flavours. Multiplex is a scary word for a simple idea: make one thing serve many users. There are exactly two ways to do it.

Read the figure as two halves. On the left (time), the same one resource is handed to A, then B, then C in a row along time — you only ever hold it in turn. On the right (space), the one resource is sliced into stacked bands A, B, C that all exist at the same moment — everyone holds their piece continuously. The picture makes the difference physical: left = take turns with the whole thing; right = keep a piece of it forever.

Why the topic needs both words: "resource management" (Role 1) is nothing but choosing which kind of multiplexing fits which resource and doing it well. The CPU can't be cut in space (an instruction can't be half-run), so it must be shared in time. RAM naturally divides into byte-slices, so it's shared in space.

3. The symbols in the utilization formula

The parent note's one formula is $U=1-p^n$. Three symbols hide in there. We define each in plain words, tie it to a picture, then say why it's needed.

Why probability at all, and not just algebra? Because we cannot predict the exact instant a process needs I/O — it depends on data, user typing, disk speed. When you can't predict an exact moment but you can say "how often on average," the right tool is probability: a number measuring "what fraction of the time." That is precisely the question the OS designer asks: "what fraction of the time is my expensive CPU wasted?"

Picture two coins. Each shows heads with probability $\frac{1}{2}$. Both heads at once? $\frac{1}{2}\times \frac{1}{2}=\frac{1}{4}$ — one quarter of the outcomes. Now stretch this: the CPU is idle only when process 1 is waiting AND process 2 is waiting AND … AND process $n$ is waiting. Multiply $n$ copies of $p$:

$P(\text{all }n\text{ waiting})=\underset{n\text{ times}}{\underbrace{p\times p\times \cdots \times p}}=p^n$

CPU busy is just "not idle," and a probability plus its opposite always sum to $1$ (something either happens or it doesn't). So:

$U=1-p^n$

Covering the edge cases so no scenario surprises you:

• $n=0$: $U=1-p^0=1-1=0$. No processes → CPU never busy. ✓
• $n=1$, $p=0$: process never waits → $U=1-0^1=1$. CPU always busy. ✓
• $p=1$: a process that waits forever. Then $p^n=1$ for any $n$, so $U=0$. Loading more useless processes helps nothing. ✓
• $n\to \infty$ with $0\le p<1$: $p^n$ shrinks toward $0$, so $U$ climbs toward $1$ — but never reaches it. This is the mathematical reason multiprogramming has diminishing returns.

The figure plots $U$ up the vertical axis against $n$ along the horizontal axis, one curve per value of $p$. Trace the pink $p=0.8$ curve: it passes through the very numbers in the example below — $0.20,0.36,0.59,0.89$ — and you can see each new process lift $U$ by a smaller step than the last, the curve bending flat as it crawls toward the dashed ceiling line at $U=1$ (the "never quite reached" edge case above). Steeper $p$ curves start lower (more waiting = more idle) but climb the same shape.

You'll see where these I/O waits truly come from in Device Drivers and I/O and Interrupts and the Timer.

4. Abstraction, interface, and the file

Why the topic needs it: Role 2 (hardware abstraction) is the act of the OS offering one interface (like the file) that hides thousands of different disks. The messy translation lives in a device driver, and the address-hiding trick behind memory is Virtual Memory and Paging.

5. The two modes and the gate

Read the figure as two rooms. The left blue box is USER mode, where apps live and privileged instructions are forbidden. The right pink box is KERNEL mode, where only the OS runs with full power. Between them stands one yellow arrow — the trap/syscall gate — and it is the only way across. There is deliberately no other opening in the wall: that single guarded door is the entire mechanism of protection in one drawing.

Why the topic needs this: Role 3 (protection) is impossible without hardware that physically refuses privileged instructions in user mode. Software checks alone could be skipped by a malicious program; a hardware fence cannot. This is also why an app can't switch off the CPU timer — disabling it is a privileged instruction, so the OS keeps its power to preempt.

Prerequisite map

Read it top-down: physical facts feed the multiplexing idea, which feeds resource management; probability feeds the utilization formula; interfaces feed abstraction; modes feed the trap gate, which feeds both protection and abstraction.

Equipment checklist

Cover the right side and answer out loud. If any stalls you, re-read that section before the parent note.