Understanding race conditions

What it is

A race condition lives in the gap between validating a thing and acting on it. If two requests arrive close enough together, both can pass a check that only one should — spending a balance twice, redeeming a single-use code more than once, exceeding a limit that was true a millisecond ago.

How you approach it

1. Find something that is supposed to happen only once, or up to a limit — a redemption, a withdrawal, a one-per-account action.
2. The check and the update are not a single step. Send many identical requests at once, before the first has finished updating the state.
3. When the limit is breached, the surplus — an extra balance, a second reward — carries the flag.

How it gets fixed

The check and the write were separate operations, so requests fired in parallel all read the old state and all passed. The limit was breached, and the flag came with the surplus. The fix is to make the check-and-update atomic — a database constraint, a lock, or a single conditional write.

Practise it

Every lab in the Race condition category drills exactly this. Start at Apprentice and work up.