A race condition happens when the correctness of a program depends on the order or timing of operations that can overlap. Two threads or processes may read or change shared state without enough coordination, leading to results that vary between runs.
For example, two workers might both check that a resource is available and then both allocate it. A separate kind of time-of-check-to-time-of-use race appears when a program checks a file or permission and the relevant state changes before the program acts on the check.
Race conditions are difficult to reproduce because they may appear only under particular workloads, processor schedules or system delays. Some merely cause incorrect output; others create data corruption, leaks or security vulnerabilities when an attacker can influence the timing.
Use correct synchronization, atomic operations and safe APIs, and design tests that exercise concurrent paths. For security-sensitive operations, avoid relying on a check that can become stale before the action it was intended to authorize.