Topic 3b – Coordinating Activities and Shared Resources

Programs and Processes

1. A program is a static set of instructions stored on disk — it is a recipe, a blueprint, a script. A process is a program in execution: it has a current state, allocated memory, a position in the code, and registers holding working values. A non-computing analogy: a cake recipe is the program; the act of baking the cake (with a specific oven, at a specific moment, with a cook following along) is the process.
2. Yes. Opening a program twice (two browser windows, two instances of a text editor) creates two separate processes, each with its own state, memory space, and position in execution — even though both are running from the same program file on disk.
3. The process table contains one entry per active process, recording its process ID, current state (running, ready, waiting), the saved contents of its CPU registers, memory allocation, and other bookkeeping information needed to resume it. The scheduler (and more specifically, the dispatcher) is responsible for maintaining and using this table.
4. A ready process has everything it needs to run and is simply waiting for the CPU to become available. A waiting process cannot run even if the CPU were free — it is blocked pending some external event (a disk read completing, user input arriving, a semaphore being released). The dispatcher only considers ready processes when selecting the next one to run; a waiting process would waste the CPU time slice, so it is skipped entirely until its event occurs.

The Dispatch Cycle

5. When an interrupt arrives mid-slice: (1) the CPU finishes the current instruction, then (2) automatically saves the current process's state (registers, program counter) to its entry in the process table — this is the context switch. (3) The CPU switches to privileged mode and transfers control to the OS interrupt handler. (4) The OS handles the interrupt (e.g., noting that a time slice expired, or that I/O completed). (5) The scheduler selects the next ready process, the dispatcher loads its saved state into the CPU registers, and execution resumes.
6. Without save/restore of process state, switching away from a process would destroy its in-progress work — the registers, program counter, and working values that define exactly where it was. Multiprogramming requires that each process can be paused and resumed exactly where it left off, potentially many thousands of times before it finishes. The context switch mechanism makes this possible.
7. The student is partly right and partly wrong. Context switches do have a small overhead cost — saving and restoring state takes a few hundred nanoseconds. Under extremely heavy load with very short time slices, this overhead can become significant (thrashing). However, in the normal case, the switching overhead is tiny compared to the time slices themselves, and the benefit is large: processes that are blocked waiting for I/O yield the CPU rather than wasting it, so the overall throughput of the system increases. The computer feels faster under reasonable load, not slower.

Shared Resources and Deadlock

8. A simple flag fails because reading the flag and setting it are two separate instructions. A context switch can occur between those two steps, allowing a second process to also read the flag as "available" and proceed — resulting in two processes inside what should be an exclusive region simultaneously. This timing-dependent failure is called a race condition.
9. A semaphore combines the test-and-set into a single, atomic (uninterruptible) hardware instruction. No context switch can occur between reading and setting the semaphore's value, eliminating the race condition. The hardware feature is the atomic test-and-set (or compare-and-swap) instruction that the CPU provides specifically to support this kind of mutual exclusion.
10. A critical region is a section of code that accesses a nonshareable resource and must not be executed by more than one process at a time. Mutual exclusion is the guarantee that only one process is in a critical region at any given moment. A semaphore enforces this by acting as a lock: before entering the critical region a process decrements the semaphore (blocking if it is already 0); upon leaving it increments the semaphore, allowing a waiting process to proceed.
11. All three classic deadlock conditions are present: mutual exclusion (each resource can only be held by one process at a time), hold and wait (each process holds one resource while waiting for another), and circular wait (A waits for B's resource while B waits for A's, forming a cycle). The fourth condition sometimes listed — no preemption — is also implied (neither process voluntarily releases what it holds).
12. One strategy per condition: eliminate mutual exclusion by making the resource shareable where possible (not always feasible); eliminate hold and wait by requiring processes to request all resources they will ever need before starting (or release all held resources before requesting a new one); eliminate circular wait by imposing a global ordering on resources so processes must always request them in the same sequence. Spooling eliminates mutual exclusion for devices like printers: instead of letting processes write directly to the printer (nonshareable), they write to a shared spool file on disk, and a single dedicated spooler process accesses the printer. The printer is no longer contested directly.