Exercise 2: Blocking's Own Benefit Still Holds When the Worker Later Needs I/O Too — Possible Solution
====================================================================

THE TEST
------------------------------
    # waiter: poll OR block on a 100-tick disk read (the variable under test)
    # worker: 150 real WORK steps, THEN its own READ_DISK_BLOCKING
    #         (same blocking discipline for the worker in BOTH runs)

RESULT
------------------------------
    waiter polls/blocks on a 100-tick op; worker does 150 real WORK
    steps then its OWN blocking disk read
    poll: 302 real steps, block: 203 real steps

Blocking still finishes noticeably faster (203 vs 302 real steps),
even though the worker now also needs the disk eventually, and even
though the worker's own I/O uses blocking in both scenarios.

WHY ISOLATING THE VARIABLE MATTERS
------------------------------
The worker's own behavior (150 WORK steps, then a blocking disk read)
is held IDENTICAL across both runs -- only the waiter's own choice
(POLL_DISK vs READ_DISK_BLOCKING) changes. This is deliberate: if the
worker's own I/O strategy also changed between runs, a difference in
total time could be explained by EITHER variable, making the
comparison ambiguous. Holding everything except the one thing being
tested constant is what makes the measured 302-vs-203 gap
attributable specifically to the waiter's own polling-vs-blocking
choice.

WHY THE ADVANTAGE STILL HOLDS
------------------------------
Nothing about Finding 1's own underlying mechanism required the OTHER
process to never touch I/O -- it only required that the waiter's own
choice affect how much of the ready-queue rotation the waiter itself
occupies while genuinely doing nothing useful. Whether the worker
LATER also blocks on its own I/O is irrelevant to that mechanism:
during the WAITER's own 100-tick wait specifically, blocking still
frees up 100% of the rotation for the worker (versus roughly half
under polling), exactly as measured in Chapter 6 and Finding 1. The
worker's own later I/O wait is a completely separate event that
happens on its own schedule, unaffected by what the waiter did earlier.

WHY THIS WORKS AS AN ANSWER
------------------------------
Testing a scenario where BOTH processes eventually need the disk --
rather than the simpler "only the waiter ever touches I/O" setup used
throughout the rest of the chapter -- rules out the possibility that
the measured speedup only holds in an artificially I/O-free "worker,"
confirming the mechanism generalizes to a genuinely more realistic
mixed workload.