Concurrency: Jiggle Testing
Race conditions hide in timing gaps — shaking execution order with random yields and multi-platform runs forces them into the open.
Why Races Are Hard to Catch
Concurrency bugs are timing-dependent: the race window may be nanoseconds wide. They disappear under a debugger (the observation changes the timing), pass on your development machine, and blow up in production under load. A test that passes 1000 consecutive times on one machine does not prove thread safety — it proves that particular timing pattern didn't trigger the race. The race is still there; you just didn't shake it loose.
The Jiggle Technique
Jiggle testing deliberately destabilizes the execution order to widen race windows: (1) insert random.sleep() or thread.yield() calls at thread-switch points; (2) run the test thousands of times with different random seeds; (3) run on multiple OS and hardware combinations — different schedulers produce different interleavings; (4) vary the thread count; (5) use stress-testing tools (Java's ConTest/jcstress, Go's race detector, Python threading stress harnesses). Automated jiggle + assertion loop = a concurrency regression test that raises the probability of exposing latent races.
Code Challenge
Add a jiggle harness to expose the race, then fix it with a lock.
💡Key takeaway
Jiggle testing widens race windows by randomizing thread scheduling. Combine it with many repeated runs and multi-platform execution to catch concurrency bugs that deterministic tests miss.
🔧 Some exercises may still have errors. If something seems wrong, use the Feedback button (bottom-right of the page) to report it — it helps us fix it fast.
Hint: The jiggle doesn't find all bugs — it raises the probability of exposing the ones that exist. Run jiggled tests thousands of times across different platforms.
✗ Your version