Exercise 3: More Processes Racing — a Surprising, Flat Result — Possible Solution ==================================================================== THE TEST ------------------------------ # QUANTUM=1, 30 increments each, run with 2, then 3, then 4 # processes all sharing ONE physical frame RESULT ------------------------------ 2 processes, 30 increments each: expected 60, got 30, lost 30 3 processes, 30 increments each: expected 90, got 30, lost 60 4 processes, 30 increments each: expected 120, got 30, lost 90 The final counter value is EXACTLY 30 every single time -- completely independent of whether 2, 3, or 4 processes are racing. The "lost" count keeps growing (30, 60, 90), but only because the EXPECTED total keeps growing while the ACTUAL result stays perfectly flat. WHY THE RESULT NEVER CHANGES ------------------------------ With QUANTUM=1 and a strict round-robin scheduler, every process gets exactly one step, in a fixed rotation, before the next one runs. In any given "round" where N processes all execute their own LOAD step in turn, every single one of them reads the SAME shared value -- because none of them has reached STORE yet to change it. When their INC and STORE steps eventually happen (also one at a time, in the same rotation), each STORE overwrites whatever the previous process just wrote -- so only the LAST process's own STORE in that stretch actually survives, no matter how many processes were competing for it. Adding more processes to the SAME round doesn't create more real progress -- it just adds more competitors overwriting each other's work within the same effective "slot." WHY THIS IS A GENUINELY DIFFERENT LESSON FROM "IT GETS WORSE" ------------------------------ The intuitive guess is that more processes racing should simply lose MORE absolute progress, in proportion to how many are competing -- which sounds bad, but still implies the achieved total climbs somewhat as more work is attempted. The real, measured result is sharper and more alarming than that: with this exact interleaving, the ACHIEVED total doesn't climb AT ALL as more processes join the race -- it's permanently capped at whatever a single process alone would have achieved. Unsynchronized concurrent access doesn't just cost some efficiency; it can make additional real work completely worthless. WHY THIS WORKS AS AN ANSWER ------------------------------ Running the identical race at three different process counts, with everything else held fixed (same quantum, same increments-per-process, same starting value), isolates process count as the only changing variable -- turning an assumption ("more races should lose more, but still make SOME progress") into a measured, surprising, and far more serious finding (achieved progress can flatline completely).