OS roles — resource management, hardware abstraction, protection: Worked examples

This page is the drill ground for OS roles — resource management, hardware abstraction, protection. We do not introduce new theory — we take the tools you already met (the utilization formula $U = 1 - p^{n}$ , the two CPU modes, the system-call gate, the MMU check) and push them through every case that can occur: every sign, every extreme, the degenerate inputs, a word problem, and an exam-style trap.

The scenario matrix

The only quantitative tool here is $U = 1 - p^{n}$ , where:

#	Cell class	What makes it special	Example
A	Typical middle case	$0 < p < 1$ , small $n$	Ex 1
B	Growing $n$ (limiting behaviour)	$n \to \infty$ , watch $U \to 1$	Ex 2
C	Degenerate $p = 0$	process never waits (pure CPU)	Ex 3
D	Degenerate $p = 1$	process always waits (pure I/O)	Ex 3
E	Boundary $n = 1$	no multiprogramming at all	Ex 3
F	Real-world word problem	translate English → $p, n$ → decision	Ex 4
G	Protection: memory access	unmapped address, MMU fault	Ex 6
H	Protection: privileged instruction	user mode + privileged op	Ex 7
I	Abstraction: same call, two devices	driver differs, contract same	Ex 8
J	Exam twist	"how many processes to hit a target $U$ ?" — invert the formula	Ex 5

The figures below carry the geometry of cells A/B (the utilization curve) and cells G/H (the protection gate). Everything else is arithmetic or logic you can follow line by line.

Part 1 — Resource management (cells A–F, J)

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

Figure s01 plots the red curve $U = 1 - 0. 8^{n}$ against $n$ (the number of loaded processes) on the horizontal axis, with utilization $U$ on the vertical axis. Read it left to right: the curve rises fast then flattens toward the dashed black line at $U = 1$ — the asymptote it hugs but never touches. The three black dots mark the exact values we compute in Ex 1 ( $n = 3$ ), Ex 2 ( $n = 10$ ), and the parent note's $n = 1$ . Keep this shape in view; it is the whole story of multiprogramming.

Worked example Ex 1 — Cell A: the typical middle case

Three I/O-heavy processes are loaded. Each waits for I/O $80%$ of the time. What fraction of the time is the CPU busy?

Forecast: Guess first — more than one process, each idle a lot. Will $U$ be closer to $0.2$ or to $0.6$ ? Commit to a number.

Identify the knobs. $p = 0.8$ , $n = 3$ . Why this step? The formula only takes these two inputs; naming them prevents plugging the wrong number into the exponent.
Compute the "all-waiting" probability. $p^{n} = 0. 8^{3} = 0.512$ . Why this step? The CPU is idle only when every one of the 3 is simultaneously waiting; independent events multiply, so it is $0.8 \times 0.8 \times 0.8$ .
Subtract from 1. $U = 1 - 0.512 = 0.488$ . Why this step? Busy time is simply "not idle time".

Answer: $U = 0.488$ , i.e. the CPU is busy $\approx 48.8%$ of the time. (This is the leftmost of the three black dots in Figure s01, at $n = 3$ .)

Verify: Sanity — with $n = 1$ we had $U = 0.2$ ; adding two more processes should raise it, and $0.488 > 0.2$ . ✓ It also sits below the $n = 4$ value ( $0.59$ ) from the parent note. ✓ Units: $U$ is a pure fraction in $[0, 1]$ , and $0.488$ is. ✓

Worked example Ex 2 — Cell B: limiting behaviour as

$n$ grows Same $p = 0.8$ . Compute $U$ at $n = 10$ and at $n = 50$ . What number is $U$ heading toward?

Forecast: The curve flattens near the top of Figure s01. Guess: does $U$ ever reach exactly $1$ ?

$n = 10$ : $p^{10} = 0. 8^{10} \approx 0.1074$ , so $U = 1 - 0.1074 = 0.8926$ . Why this step? Ten independent waiters all pausing at once is now unlikely, so idle time is small. This is the rightmost black dot in Figure s01.
$n = 50$ : $p^{50} = 0. 8^{50} \approx 1.427 \times 1 0^{- 5}$ , so $U = 1 - 0.0000143 \approx 0.99999$ . Why this step? $0. 8^{50}$ is a tiny number — the chance all 50 wait simultaneously is essentially zero.
Limit: As $n \to \infty$ , $p^{n} \to 0$ (any base with $0 < p < 1$ raised to a growing power shrinks to 0), so $U \to 1$ . Why this step? This is the mathematical reason the curve approaches but never touches the dashed line $U = 1$ in Figure s01 — the classic asymptote (the horizontal line the curve hugs forever without reaching).

Answer: $U (10) \approx 0.893$ , $U (50) \approx 0.99999$ , and $U \to 1$ but never equals $1$ .

Verify: $0.893 > 0.488$ (Ex 1) and $0.99999 > 0.893$ — monotonically increasing as $n$ grows. ✓ The limit $1$ is an upper bound the fraction can never exceed since $p^{n} > 0$ always for finite $p > 0$ . ✓

Worked example Ex 3 — Cells C, D, E: the three degenerate inputs

Handle the extreme inputs the formula must still survive. (C) $p = 0$ , any $n$ . (D) $p = 1$ , any $n$ . (E) $n = 1$ , any $p$ .

Forecast: One of these gives $U = 1$ , one gives $U = 0$ , and one collapses the formula to something you already know. Match them up before reading.

Cell C — $p = 0$ (process never waits, pure CPU work). $p^{n} = 0^{n} = 0$ for any $n \geq 1$ , so $U = 1 - 0 = 1$ . Why this step? If a process never pauses for I/O, one process alone keeps the CPU $100%$ busy — adding more can't raise busyness above $100%$ , it just makes them queue. The formula correctly caps at $1$ .
Cell D — $p = 1$ (process always waits, never uses CPU). $p^{n} = 1^{n} = 1$ , so $U = 1 - 1 = 0$ . Why this step? If every process is always stuck waiting, the CPU literally never has work — utilization is $0$ no matter how many you load. The formula gives exactly $0$ . ✓
Cell E — $n = 1$ (no multiprogramming). $U = 1 - p^{1} = 1 - p$ . Why this step? With a single process, the CPU is busy exactly when that process is not waiting — probability $1 - p$ . This recovers the parent note's $n = 1$ result and shows the formula degrades gracefully.

Answers: (C) $U = 1$ , (D) $U = 0$ , (E) $U = 1 - p$ .

Verify: Plug $p = 0.8, n = 1$ into (E): $U = 1 - 0.8 = 0.2$ — matches the parent note exactly. ✓ Both boundary values $U = 1$ and $U = 0$ lie inside $[0, 1]$ . ✓

Worked example Ex 4 — Cell F: real-world word problem

A web server runs many request-handlers. Measurement shows each handler is blocked on network/disk $90%$ of its lifetime. The ops team wants CPU utilization of at least $85%$ . Roughly how many handlers must be loaded?

Forecast: $p$ is high ( $0.9$ ), so each handler is idle a lot — you'll probably need more handlers than in the $p = 0.8$ examples. Guess a number.

Translate English to knobs. "blocked $90%$ " ⟹ $p = 0.9$ . "at least $85%$ busy" ⟹ require $U \geq 0.85$ . Why this step? The whole word problem reduces to one inequality once you name $p$ and the target.
Set up the inequality. $U = 1 - 0. 9^{n} \geq 0.85 \Rightarrow 0. 9^{n} \leq 0.15$ . Why this step? We invert "busy $\geq 0.85$ " into "idle $\leq 0.15$ ", which is the term we can solve.
Solve for $n$ using logarithms. Take the natural logarithm $ln$ (log to base $e$ — any base works here because the base cancels in the ratio, so we use $ln$ for definiteness) of both sides: $n ln (0.9) \leq ln (0.15)$ . Since $ln (0.9) < 0$ , dividing flips the inequality: $n \geq \frac{ln 0.15}{ln 0.9} = \frac{- 1.8971}{- 0.10536} \approx 18.006$ . Why a logarithm here, and not something else? We have the unknown in the exponent ( $0. 9^{n}$ ). The log is the exact tool that "pulls the exponent down" so we can isolate $n$ — that is precisely the question a logarithm answers ("what power gives this value?").
Round up to a whole process. The threshold $18.006$ is just above $18$ , so $n = 18$ does not yet clear the bar — we need the next whole number, $n = 19$ . Why round up (and why 19, not 18)? $n$ must be an integer and we need $U$ to reach or exceed $0.85$ . Since the exact crossing point $18.006$ lies past $18$ , the smallest integer that satisfies the requirement is $19$ .

Answer: 19 handlers.

Verify: $0. 9^{18} \approx 0.1501 > 0.15$ , so $U (18) \approx 0.8499 < 0.85$ — fails the target. $0. 9^{19} \approx 0.1351 < 0.15$ , so $U (19) \approx 0.8649 \geq 0.85$ — meets it. ✓ So $19$ is the smallest count that works, confirming the round-up. ✓ Note $19$ handlers for $p = 0.9$ vastly exceeds the handful needed at $p = 0.8$ — matches the intuition that idler processes need more of them. ✓

Worked example Ex 5 — Cell J: the exam twist (invert the formula)

Exam question: "With $p = 0.5$ , what is the smallest number of processes that pushes CPU utilization above $95%$ ?" You are given $U$ and $p$ ; find $n$ — the reverse of Ex 1–3.

Forecast: $p = 0.5$ is much lower than earlier examples (processes wait only half the time), so each added process helps a lot. Will you need many or few?

Write the requirement. $U = 1 - 0. 5^{n} > 0.95 \Rightarrow 0. 5^{n} < 0.05$ . Why this step? Same inversion as Ex 4: "busy $> 0.95$ " becomes "idle $< 0.05$ ".
Solve for the exponent with logarithms. Take the natural logarithm $ln$ of both sides: $n ln (0.5) < ln (0.05)$ . Since $ln (0.5) < 0$ , dividing flips the inequality: $n > \frac{ln 0.05}{ln 0.5} = \frac{- 2.9957}{- 0.6931} \approx 4.32$ . Why a log again, and why $ln$ ? The unknown $n$ is in the exponent of $0. 5^{n}$ ; the logarithm is the one operation that isolates an exponent. The base of the log cancels in the ratio, so any base gives the same answer — we pick $ln$ for definiteness.
Round up to the next whole number. The exact crossing is at $\approx 4.32$ , so the smallest integer above it is $5$ . Why round up (not down)? At $n = 4$ the target isn't met yet; we need the first integer that clears the bar, which is $5$ .

Answer: $n = 5$ processes.

Verify: $0. 5^{4} = 0.0625 \Rightarrow U = 0.9375 < 0.95$ (not enough). $0. 5^{5} = 0.03125 \Rightarrow U = 0.96875 > 0.95$ (clears it). ✓ So $5$ is indeed the smallest. Fewer processes needed than the $p = 0.9$ case (Ex 4) — matches the "less idle ⟹ fewer needed" intuition. ✓

Part 2 — Protection & abstraction (cells G, H, I)

Figure s02 draws the two privilege levels as two black boxes: USER MODE on the left (app code, limited power) and KERNEL MODE on the right (the OS, full power). The single red arrow between them is the only legal path — a trap/syscall. The black X below it marks where an illegal attempt (a bad address or a privileged instruction) is stopped and bounced back. In the two protection traces below, I will point to exactly which arrow each step travels.

Worked example Ex 6 — Cell G: process reads memory it doesn't own

Process A runs mov rax, [0x7fff_B000], an address that belongs to process B. Trace exactly what happens, step by step.

Forecast: Does A read B's data, get zeros, or get killed? Decide first.

CPU issues the memory access. The virtual address 0x7fff_B000 is handed to the MMU (Memory Management Unit — the hardware that translates addresses). In Figure s02 we are still inside the left USER MODE box. Why this step? Every single memory access in user mode passes through the MMU; there is no bypass.
MMU consults A's page table. It looks up 0x7fff_B000 in A's mapping — not B's, because the CPU is currently running A. Why this step? Each process has its own page table; the MMU only ever uses the table of the running process, which is what enforces isolation.
No valid mapping ⟹ page fault. The address is not mapped for A, so the MMU raises a fault. This is the black X in Figure s02 — the illegal access is caught, and the CPU is forced across into KERNEL MODE via the trap. Why this step? An unmapped access is exactly the condition the MMU is built to catch; it cannot silently return B's data.
OS decides policy. Now inside the right KERNEL MODE box, the kernel sees an illegal access and terminates A with a segmentation fault (SIGSEGV). B is never touched. Why this step? Hardware detects; the OS decides the consequence — "mechanism vs policy".

Answer: A is killed with SIGSEGV (segmentation fault); B's memory is completely safe.

Verify: Consistency check — the only way A could read B would be a mapping of B's page in A's table, which by design does not exist. So the outcome cannot be "A reads B's data". ✓ This mirrors the parent note's segfault example. ✓ See Virtual Memory and Paging and Kernel vs User Mode.

Worked example Ex 7 — Cell H: process tries a privileged instruction

A user program executes the privileged "disable timer interrupt" instruction, hoping to hog the CPU forever. Trace it.

Forecast: Will it succeed in freezing the scheduler, or fail? And what enforces the result — software or hardware?

CPU checks the mode bit. The mode bit currently says user mode (the program isn't the kernel). In Figure s02 we start in the left USER MODE box. Why this step? Every instruction fetch carries a privilege check when the opcode is privileged; the mode bit is the single source of truth.
Privileged opcode in user mode ⟹ trap. The CPU refuses to execute and raises a general-protection trap. This is again the black X in Figure s02: the illegal instruction is blocked, and the CPU is forced across into KERNEL MODE. Why this step? This is enforced in silicon — the program cannot "skip the check" because it isn't software doing the checking.
OS regains control. Now inside the right KERNEL MODE box, the kernel handles the trap and can kill or penalise the offender. The timer is never disabled. Why this step? Because the timer stays armed, the next timer interrupt will still fire, so the scheduler can still preempt — the process cannot monopolise the CPU.

Answer: The instruction faults; the OS keeps control; the CPU can never be monopolised this way.

Verify: Logical closure — Role 1 (scheduling) depends on Role 3 (protection): if this instruction had succeeded, time-slicing would break. Since it faults, the dependency holds. ✓ See CPU Scheduling and System Calls and Traps.

Worked example Ex 8 — Cell I: same call, two different devices

The identical line read(fd, buf, 512) is run once when fd refers to a file on an SSD, once when it refers to a file on a USB HDD. What is the same, what differs?

Forecast: Which layer changes between the two runs — the system call, the file system, or the driver?

Same contract at the top. Both runs execute the same read system call with the same arguments, crossing the same trap gate into the kernel. This is the red arrow of Figure s02 — used identically in both runs. Why this step? The system-call interface is the fixed contract; the application is written once against it.
Same generic layers. File system and block layer treat "read 512 bytes from this file" identically for both. Why this step? These layers speak in the abstraction (files, blocks), not in device hardware.
Driver differs at the bottom. The SSD driver pokes flash-controller registers to fetch the block; the HDD driver instead issues a seek+read command that moves a physical head over a spinning platter. Only this bottom layer changes between the two runs. Why this step? The driver is exactly the box where device-specific mess is quarantined — swap the disk, swap the driver, app unchanged.

Answer: Everything above the driver is identical (same system call, same file/block layers); only the driver at the bottom differs. That is hardware abstraction delivering portability.

Verify: Falsifiable claim — if the abstraction were leaky, the app's source would need an #ifdef SSD. It doesn't. ✓ Matches the parent note's "same code, two devices" example. ✓ See Device Drivers and I/O.

Recall Quick self-test across the whole matrix

With $p = 0.8$ , what is $U$ at $n = 3$ ? ::: $1 - 0. 8^{3} = 0.488$ As $n \to \infty$ for any $0 < p < 1$ , what does $U$ approach and does it reach it? ::: Approaches $1$ but never reaches it (asymptote). If $p = 0$ , what is $U$ for any $n$ ? ::: $U = 1$ (never waits, always busy). If $p = 1$ , what is $U$ ? ::: $U = 0$ (always waiting, CPU idle). Which mode is the CPU in when a user program starts a privileged instruction, and what results? ::: User mode ⟹ trap to kernel; instruction faults. When A reads B's memory, why is B safe? ::: The MMU uses A's page table, finds no mapping, faults — it can never reach B. To hit $U \geq 0.85$ with $p = 0.9$ , how many processes? ::: 19 (since the crossing is at $\approx 18.006$ , round up past 18). To exceed $U = 0.95$ with $p = 0.5$ , how many processes? ::: 5 (crossing at $\approx 4.32$ , round up). What is a register such as rax? ::: A tiny fast storage slot inside the CPU that instructions read and write. What is SIGSEGV? ::: The signal that kills a process after an illegal memory access — the "segmentation fault".