Given. 180 tracks, numbered 0–179. The head is currently at track 141 and has just finished a request at track 130, so it is travelling in the increasing direction (130 → 141). Pending FIFO queue: 96, 157, 101, 176, 104, 160, 116, 174, 150. Head movement is measured from the current position, 141.
Find. Total head movement for (i) FIFO order, (ii) SSTF, (iii) SCAN.
Approach. (i) Service strictly in queue order, summing consecutive absolute differences. (ii) Always move to the closest pending request. (iii) SCAN continues in the current direction of travel (upward, since the head moved from 130 to 141) all the way to the physical end of the disk (track 179), servicing every request it passes, then reverses; on the return leg it travels only as far as the lowest remaining request, since nothing lies beyond it.
Fig. Q6(a) — track positions on the 0–179 platter. SCAN sweeps up to track 179 first (the head is travelling upward, from 130 to 141), then reverses and descends only as far as the lowest pending request, 96.
(i) FIFO — service in the given queue order. $141\to96\to157\to101\to176\to104\to160\to116\to174\to150$:
$$45+61+56+75+72+56+44+58+24 = 491$$
$$\boxed{\text{FIFO total} = 491\text{ tracks}}$$
(ii) SSTF — always serve the nearest pending request. From 141 the nearest request is 150 (9 away; 116 is 25 away), then 157 (7) → 160 (3) → 174 (14) → 176 (2); the nearest remaining is then 116 (60) → 104 (12) → 101 (3) → 96 (5).
$$9+7+3+14+2+60+12+3+5 = 115$$
$$\boxed{\text{SSTF total} = 115\text{ tracks (order }150,157,160,174,176,116,104,101,96\text{)}}$$
(iii) SCAN — continue up to the disk end, then reverse. Moving up from 141, the head services 150, 157, 160, 174, 176 on the way to track 179 (distance $179-141=38$); it then reverses and descends, servicing 116, 104, 101, 96, stopping at the lowest pending request, 96 (distance $179-96=83$).
$$38+83=121$$
$$\boxed{\text{SCAN total} = 121\text{ tracks}}$$
For comparison, LOOK (reversing at 176 instead of the disk end) would give $35+80=115$, the same as SSTF here.
(b) Multiple processes vs. multiple threads. Prefer threads when the concurrent tasks are logically part of one application and benefit from fast, low-overhead communication and shared state (shared address space means no IPC setup, cheaper creation/context-switch, and direct access to common data) — e.g. a GUI thread kept responsive while a worker thread computes. The cost is weak fault isolation: since all threads share one address space, a bug (bad pointer, stack overflow) in one thread can corrupt or crash the entire process. Prefer multiple processes when strong isolation, fault containment, or security boundaries matter more than communication speed — a crash in one process cannot directly corrupt another's memory (e.g. a browser's per-tab process model) — at the cost of higher creation/context-switch overhead and slower communication via IPC (pipes, shared-memory setup, message passing) instead of direct memory access. The choice is a trade-off between performance/shared-state convenience (threads) and robustness/isolation (processes), driven by how much the components need to trust each other.
(c) Why the optimal CPU scheduling strategy is hard to implement. For minimum average waiting (and turnaround) time the optimal strategy is Shortest-Job-First, or its preemptive form SRTF. It is hard to implement on a real system for several reasons:
Burst lengths are unknown in advance. SJF/SRTF needs the length of each process's next CPU burst before the burst runs. A general-purpose OS cannot know this; it can only predict it, for example by exponential averaging of past bursts, $\tau_{n+1}=\alpha t_n+(1-\alpha)\tau_n$. A wrong prediction gives a non-optimal schedule.
Future arrivals are unknown. A truly optimal schedule is an offline result: it assumes the whole job set is known. A real scheduler decides online, as processes arrive and block for I/O, so a decision that looks best now can be poor once a new short job arrives.
"Optimal" depends on the goal, and the goals conflict. Minimum average waiting time, short response time for interactive users, high throughput, high CPU utilization, meeting deadlines and fairness cannot all be optimized together. SJF is optimal for average waiting time but can starve long jobs indefinitely.
Overhead. Computing the ideal choice, keeping burst estimates, and preempting often (SRTF) cost CPU time and context switches, which themselves reduce the benefit. On multiprocessor systems optimal scheduling is a combinatorial problem that is far too expensive to solve at every decision.
Real systems therefore use approximations such as multilevel feedback queues, which infer burst behaviour from how processes used their previous time quanta.
