Race Condition

A race condition is a correctness failure or unpredictable behavior that occurs when the outcome of concurrent operations depends on their relative timing or interleaving. The same inputs can produce different results because reads, writes, checks, commands or events happen in an unsafe order.

Race conditions appear in operating systems, concurrent services, embedded firmware, distributed systems, digital logic, control gateways and shared-state workflows. They are dangerous because they may pass ordinary tests and fail only under specific timing, load, scheduling, retry or hardware conditions.

Timing-Dependent Outcome

A race condition exists when there are at least two operations:

and two possible interleavings:

that produce different observable states:

when the engineering requirement expects one valid state. The issue is not merely that work is concurrent. The issue is that required ordering or atomicity is missing.

Shared-State Invariant

Race analysis should name the invariant. For a resource with starting amount:

confirmed uses:

and remaining amount:

a conservation invariant can be written:

An invariant residual is:

If:

the system has lost, duplicated or over-applied state.

Race Window

Many races occur during a window between check and update. Let race window duration be:

and competing arrival rate be:

A simple expected-overlap screen is:

If arrivals are approximated as Poisson, the probability of at least one competing arrival during the window is:

This is a screening calculation, not proof. Real systems have bursts, retries, scheduler artifacts, hot keys and correlated clients.

Lost Update

A common race is a lost update. Two actors read the same old value:

Each computes:

If both write x_1, the observed result is:

but the correct result for two successful updates is:

The lost update error is:

Worked Example

A reservation service starts with:

unit available. Two clients concurrently reserve the same item. Both read:

before either write is visible. Both confirm success and write remaining inventory:

The system records:

The invariant residual is:

The negative residual means the system oversold one unit even though the stored inventory did not go negative.

Now estimate the race exposure. If the unsafe read-modify-write window is:

and requests for the hot item arrive at:

then:

The simplified overlap probability is:

This is high enough that a race is not a rare theoretical edge case. The design needs atomic update, conditional write, transaction isolation, single-owner queue, idempotency guard or another correctness mechanism.

Mitigation

Mitigations depend on the invariant. Options include atomic compare-and-swap, transactional update, row-level lock, optimistic concurrency with version check, single-writer ownership, message ordering, sequence counters, idempotency keys, immutable event logs, conflict detection, retry with fresh read, and state-machine redesign.

The mitigation must preserve the required behavior under failure. A retry after conflict is acceptable only if it cannot duplicate side effects. A lock protects correctness but may introduce lock contention. A queue can serialize work but may create latency. A transaction can protect state but may increase dependency load.

Relationship To Neighbor Terms

Lock contention is a performance problem caused by waiting on synchronization. A race condition is a correctness problem caused by insufficient ordering or atomicity. The two can trade off: adding a lock may remove a race while creating contention. Idempotency keys prevent duplicate side effects across retries. Sequence counters and data-age checks help detect stale or out-of-order commands. The concurrency load-test project turns these concepts into a validation deliverable.

Validation Evidence

Validation should include a minimal reproducer, high-concurrency load test, hot-key test, randomized scheduling, fault injection, retries, restart behavior, duplicate requests, trace evidence, invariant reconciliation, and retest after mitigation. Logs should identify operation id, actor, key, read version, write version, result, timing and conflict response.

The strongest evidence is not a clean run alone. It is a test that fails before the mitigation, passes after the mitigation, and checks the invariant directly.

Common Mistakes

The most common mistake is assuming that low probability means no risk. If the race window is exercised many times per second, rare timing can become routine. Another mistake is treating the symptom as a performance issue when the real failure is state corruption. A third is adding retries without idempotency, which can amplify the race. A fourth is hiding the issue with a lock and never validating contention, priority inversion or deadline effects.

A strong race-condition review states the invariant, unsafe interleaving, race window, reproduction method, mitigation, retest evidence and residual concurrency risk.