Question bank — OS roles — resource management, hardware abstraction, protection

False. One core executes one instruction stream at a time; the OS switches between programs so fast it looks simultaneous. That's concurrency (time-slicing), not parallelism — parallelism needs multiple cores. See CPU Scheduling.

False. Each program is not sped up at all — it may even run slower per-program. Utilization rises because while one process waits for I/O, another can use the otherwise-idle CPU.

False. A library runs with the caller's privileges; the OS runs in a separate, more-powerful CPU mode (Kernel vs User Mode) and owns the hardware. It is a trusted referee, not a helper the app fully controls.

False. Software alone can be skipped by a malicious program. Enforcement needs hardware — the CPU's mode bit and the MMU physically refuse illegal actions. The OS decides policy; hardware supplies mechanism.

Partly true, but that isn't its primary purpose. A uniform interface does aid OS maintainability — driver code is neatly separated from the core. Yet the main driver is portability for applications: the same read() works on HDD, SSD, or USB. Both benefits are real; the app-facing one is why the abstraction is shaped the way it is.

False. A file is an abstraction the OS presents over raw sectors/flash blocks. The disk stores bytes in blocks; "file" is the clean interface (open/read/write/close) layered on top.

False. With $p=0$ (never waiting) the idle probability $p^n=0$ already, so one process alone keeps the CPU 100% busy. Multiprogramming helps because real jobs wait for I/O; without waiting, there's no idle time to reclaim.

False. Disabling the timer is a privileged instruction; attempting it in user mode traps to the kernel. This is exactly why one process can never permanently hog the CPU — resource management depends on protection.

False by default. Each process has its own page table, so the same virtual address normally maps to different physical frames — that's isolation. The one deliberate exception is shared memory: if the OS is explicitly asked to map a region into both processes, their virtual addresses can point at the same physical frame. Isolation is the default; sharing happens only when requested and granted.

Error: the app never touches the disk. read is a system call that hands control to the kernel, which walks file system → block layer → driver → controller. The app only sees the contract.

Error: a segfault is a memory-protection event — the process touched an address not mapped in its page table, the MMU raised a fault, the OS killed it. It has nothing to do with disk space.

Error: if user code could set its own privilege, protection would be meaningless. The switch happens only through a controlled gate — a trap/syscall instruction or a hardware interrupt — after which the OS, not the app, is running.

Error: only if no other runnable process exists. With multiprogramming the OS schedules another ready process, so the CPU stays busy while one process waits. Idle requires all loaded processes waiting.

Error: it's the opposite — the abstraction exists so your program is unchanged. You swap the driver; the open/read/write contract stays fixed, so the app doesn't care what device is underneath.

Error: user programs run in user mode with restricted instructions. Only the OS runs in kernel mode. Confusing the two erases the protection boundary entirely.

Because a malicious or buggy program can simply not call the check and jump straight to the forbidden action. Only hardware that refuses at the instruction level (mode bit, MMU) can't be bypassed.

Without a periodic forced return to the OS, a process that never yields (e.g. while(1){}) would keep the CPU forever. The timer guarantees control comes back so the scheduler can preempt it.

A single, validated entry point lets the OS check every request (arguments, permissions) before acting. Many uncontrolled doors would each be an attack surface; one gate keeps the referee in charge.

Protection keeps the timer safe so resource management can preempt; abstraction is delivered through the protected syscall gate; and resource management schedules the very abstractions (processes, virtual memory) that abstraction defines. One tension → three interlocking answers.

Utilization is $U=1-p^n$, and $p^n$ shrinks geometrically — each extra process multiplies the already-small idle probability by $p$ again. So the first few processes recover most of the idle time (steep drop in the figure) and later ones add little (the curve flattens).

It bundles a time slice of a CPU core (time-multiplexed via scheduling) with a private address space (space-multiplexed memory). Together they give each program the illusion of its own machine.

100%. With $p=0$, $U=1-0^1=1$. There's no waiting, so the single process keeps the CPU fully busy — multiprogramming would add nothing here.

No. With $p=1$, $p^n=1^n=1$ for every $n$, so $U=1-1=0$ no matter how many such processes you load. The CPU stays $0\%$ busy — the real bottleneck is the I/O device, not the CPU, and adding processes can't reclaim time that never becomes available.

Barely. When $p$ is near $1$, $p^n$ stays large even for sizeable $n$, so $U$ climbs slowly. You need many processes to reclaim meaningful CPU time — and if $p$ hits exactly $1$, you get nothing at all (previous item).

The kernel validates the address against the process's page table before using it; an invalid one is rejected (an error return), not blindly dereferenced. This is why syscall argument checking exists — the kernel must never trust user-supplied pointers.

Not enforceably. It could ask programs to behave, but any program could touch any memory or hardware. Real isolation requires the dual-mode bit and an MMU; without them, protection is only a polite convention.

The OS runs an idle loop (or halts the core to save power) until an interrupt arrives. Plugging $n=0$ into the formula uses the rule $p^0=1$, giving $U=1-1=0$ — exactly $0\%$ busy, which matches "no work to do." This is the degenerate boundary of $U=1-p^n$.

No. The MMU blocked the access before any bytes were read, so the target's memory is untouched. Only the offending process dies — that's the whole point of isolation.