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

(a) Resource management — the CPU is time-multiplexed; taking turns is scheduling. (b) Abstraction — the read interface hides device-specific details behind one uniform contract. (c) Protection — the MMU + OS stop a process from reaching resources it isn't permitted to. (d) Resource management — RAM is space-multiplexed; handing out slices is allocation.

Mnemonic check: "The OS shares (R), hides (A), guards (P)."

(a) False. On one core it is fast switching (time-slicing → concurrency), not true parallelism. True parallelism needs multiple cores. (b) False. "Set timer" is a privileged instruction. Attempted in user mode, the CPU raises a trap and the OS regains control. (c) False. The open/read/write system-call contract is unchanged; only the device driver behind it changes. That is the whole point of abstraction.

Use $U=1-p^n$ with $p=0.5$.

• $n=1$: $U=1-0.5^1=1-0.5=0.50$ → 50%.
• $n=2$: $U=1-0.5^2=1-0.25=0.75$ → 75%.
• $n=3$: $U=1-0.5^3=1-0.125=0.875$ → 87.5%.

What it looks like: each extra process cuts the idle probability $p^n$ in half. Idle goes $0.5\to 0.25\to 0.125$ — see the shrinking gap in the figure below.

We need $1-0.8^n>0.90$, i.e. $0.8^n<0.10$. Test values:

• $n=10$: $0.8^{10}\approx 0.1074$ → $U\approx 0.893$ (just short).
• $n=11$: $0.8^{11}\approx 0.0859$ → $U\approx 0.914$ (over 0.90 ✓).

So $n=11$ processes is the smallest count that clears 90%.

Why so many? With $p=0.8$ each process is idle 80% of the time; you need a big crowd so that at every instant someone is ready to run.

1. A issues the load. The CPU hands addr_in_B to the MMU (hardware).
2. The MMU looks the address up in A's page table — not B's. Each process has its own table; A's table has no valid mapping for B's memory.
3. Lookup fails → MMU raises a page fault (hardware detects the violation). B is already safe here: the read never reaches physical memory.
4. The fault traps into kernel mode. The OS inspects it, sees an illegal access, and terminates A with SIGSEGV (policy — the OS decides what to do).

Split of labour: hardware enforces (the MMU physically blocks and traps), the OS decides policy (kill A, leave B running). Neither alone suffices — software checks could be skipped by malware, so the CPU/MMU backs the referee up.

Mechanism: Scheduling relies on the timer interrupt to snatch the CPU back after a process's time slice. "Set/disable timer" is a privileged instruction, blocked in user mode by dual-mode operation (a mode bit in the CPU). Without protection: a user process could disable the timer interrupt. Then no interrupt fires, the OS never regains control, and that process hogs the CPU forever (a spin-loop would freeze the machine). Fair time-sharing collapses. Conclusion: protection is the precondition that makes preemptive scheduling possible — you cannot enforce turns if a player can pocket the referee's whistle.

1. read is a system call → executes a trap instruction → CPU switches user→kernel mode. (P: the protected gate — the only legal door into the kernel.)
2. The OS validates fd and that buf lies in your address space. (P: isolation check.)
3. The OS treats the disk as a file and asks the file system for the right blocks; you never see sectors or flash pages. (A: uniform interface over messy hardware.)
4. The data isn't ready yet (disk is slow), so the OS blocks your process and schedules another one to keep the CPU busy. (R: time-multiplexing during I/O wait — exactly the $U=1-p^n$ effect.)
5. When the disk finishes, an interrupt fires, the OS copies the bytes into buf, and marks you runnable again. (R again + P: the copy is done by the trusted kernel.)

One call, all three roles. That's why the note says they interlock: abstraction is delivered through the protected gate, and the wait is filled by resource management.

• Protection breaks: direct controller access is a privileged operation. Allowing it means any app can issue raw disk commands — reading or overwriting another program's (or the OS's) files. Isolation is gone.
• Abstraction breaks: the app now codes to this exact controller. Swap the disk model and the app stops working — no portability. Every app would need per-device code.
• (Bonus, Resource management) two apps hitting the controller at once with no referee → interleaved commands corrupt each other's transfers.

Verdict: the tiny speed gain isn't worth losing all three guarantees. The system-call detour is the safety.

The gain of adding one process is $\Delta U=(1-p^{n+1})-(1-p^n)=p^n-p^{n+1}=p^n(1-p)$. With $p=0.8$, $1-p=0.2$:

• $n=1\to 2$: $\Delta U=0.8^1\times 0.2=0.16$ → +16 percentage points.
• $n=9\to 10$: $\Delta U=0.8^9\times 0.2=0.1342\times 0.2\approx 0.0268$ → +2.7 points.

Diminishing returns: each added job helps less than the last (the factor $p^n$ decays geometrically). See the flattening curve in the figure.

Design lesson: don't cram in unlimited processes. Beyond a point the utilization gain is tiny while each extra process still costs RAM and context-switch time — the OS must balance $U$ against memory pressure. This is why schedulers cap the degree of multiprogramming.

With independent jobs, idle probability is the product of each job's wait probability. For a uniform batch of $n$ identical jobs this is $p^n$.

• 4 X-jobs: $U=1-0.9^4=1-0.6561=0.3439$ → about 34.4%.
• 4 Y-jobs: $U=1-0.3^4=1-0.0081=0.9919$ → about 99.2%.

Reading it: CPU-bound Y-jobs already keep the CPU near-saturated with just 4 of them. The heavy-I/O X-jobs leave the CPU 65.6% idle even at $n=4$ — they need far more concurrency to fill the gaps.

Which justifies multiprogramming? The X (I/O-heavy) mix: multiprogramming's whole payoff is filling I/O-wait gaps, and X has enormous gaps. Y is already busy, so extra jobs add little. The economic argument for OS resource management is strongest exactly for I/O-bound workloads.

Three roles ::: Resource management, Abstraction, Protection — "RAP". Utilization formula ::: $U=1-p^n$, idle when all $n$ jobs wait. Gain of one more process ::: $\Delta U=p^n(1-p)$ — shrinks geometrically (diminishing returns). Why protection enables scheduling ::: the timer interrupt is privileged; apps can't disable it, so preemption always works. The only legal user→kernel path ::: the system call / trap.