Exercise 1: With Zero Other Ready Processes, Polling and Blocking Tie Exactly — Possible Solution ==================================================================== THE TEST ------------------------------ sched = Scheduler() # genuinely empty -- no other process at all # solo process: poll vs block, latency=50, same disk RESULT ------------------------------ solo process, latency=50: poll takes 52 steps, block takes 52 steps The two modes finish in EXACTLY the same number of real steps. WHY THEY TIE EXACTLY ------------------------------ Blocking's own entire advantage, measured throughout this chapter and Chapter 6, comes from ONE specific mechanism: removing the waiter from the ready-queue rotation frees up real scheduled turns for OTHER processes to use instead. With scheduler.ready_queue genuinely empty, there is no other process to hand those freed-up turns to -- when the waiter blocks, self.current_pcb simply becomes None, and the CPU sits idle until the disk interrupt fires and wakes it back up. No work gets done faster anywhere in the system, because there was never any other work waiting to be done. Polling, meanwhile, wastes real scheduled turns checking a flag that isn't true yet -- but with nobody else competing for the CPU, those "wasted" turns aren't actually taken FROM anyone. The waiter simply spins in place, checking POLL_DISK over and over, until the disk completes -- consuming exactly the same number of real steps as blocking's own idle wait. WHY THIS IS THE LOGICAL EXTREME OF FINDING 2 ------------------------------ Finding 2 measured the speedup shrinking as the number of competing processes grew: 1.98x at 1 competitor, down to 1.01x at 8. This exercise sits at the far end of that same trend, at 0 competitors -- and the pattern holds exactly: the speedup at 0 other processes is 1.00x, a perfect tie. Blocking's own real value is entirely a function of how much OTHER useful work exists to fill the freed-up rotation slots with; it isn't some inherent property of blocking itself. WHY THIS WORKS AS AN ANSWER ------------------------------ Testing the true zero-competitor edge case, rather than stopping at Finding 2's own smallest tested value (1 competitor), confirms the trend actually reaches its logical floor rather than just approaching it -- and reveals precisely WHY blocking helps: not because blocking is intrinsically efficient, but because it correctly gives away CPU time that would otherwise be wasted, and giving away time only matters if someone else can use it.