Exercise 3: The Theoretical 2x Ceiling, Confirmed Directly at the Extreme — Possible Solution
====================================================================

THE TEST
------------------------------
    # latency=1,000,000 (effectively infinite relative to 50 real WORK steps)
    # n_other_processes=1, target_work=50

RESULT
------------------------------
    latency=1,000,000: poll=100 steps, block=51 steps, speedup=1.9608x

Blocking finishes in essentially one real step per unit of work (51
steps for 50 units -- just 1 step of fixed startup overhead), while
polling still needs exactly 100 steps, the same 2x-target-work result
Finding 1 confirmed is completely independent of latency.

WHY THE SPEEDUP CAN'T EXCEED 2.0x
------------------------------
Under strict 2-process round-robin, EVERY real step is spent running
EITHER the waiter OR the worker -- there's no third option, and no
step is ever wasted on scheduling overhead beyond the one real step
each turn already costs. Polling's own worst case is exactly 2 real
steps per unit of the worker's own progress (one step for the
worker's own WORK, one step "wasted" on the waiter's own useless
poll) -- it can never be WORSE than 2x, because the waiter never
consumes MORE than one turn out of every two. Blocking's own best
case is exactly 1 real step per unit of the worker's own progress
(the waiter is entirely absent from the rotation for as long as it
takes the worker to finish) -- it can never do BETTER than 1x, because
there's no way to make the worker's own real steps costs less than
one real step apiece. The ratio between polling's own floor (2x) and
blocking's own floor (1x) is exactly 2.0 -- a hard mathematical
ceiling built into the round-robin scheduling model itself, not an
empirical coincidence.

WHY THE MEASURED RESULT LANDS SO CLOSE TO IT
------------------------------
The 1 extra step in block's own 51-step total is simply the one real
turn the waiter itself consumes to issue READ_DISK_BLOCKING before
blocking -- an unavoidable, fixed cost that happens exactly once,
regardless of how long the subsequent wait turns out to be. As
latency (and therefore total real steps) grows arbitrarily large,
that one fixed step becomes a vanishingly small fraction of the
total, pushing the measured speedup arbitrarily close to -- but,
strictly, never quite reaching -- the true mathematical limit of 2.0x
exactly.

WHY THIS WORKS AS AN ANSWER
------------------------------
Deliberately pushing latency far beyond anything realistic (1,000,000
ticks for 50 units of work) isolates the asymptotic behavior directly,
rather than inferring it by eye from Finding 1's own more modest
values (1.90x, 1.99x) -- confirming the curve genuinely converges to
2.0x, not to some other nearby number that merely looks similar at
smaller scales.