Review Race Condition

A race condition occurs when a system's result depends on the relative timing or order of operations that can overlap. Changing that timing or order may change the result.

Two actions are using or changing the same thing without enough coordination. Each action may look reasonable by itself, but different interleavings can produce different results.

Race conditions can create intermittent failures that are difficult to reproduce because the same actions may succeed or fail depending on timing. The same pattern can appear in human workflows when people update shared information from different copies or act before another step is complete.

Two software processes read version 1 of the same record. Each calculates a different update and writes it back. One update overwrites the other. In a human workflow, two coworkers edit separate copies of the same task list and upload them without reconciling their changes. The final list depends on when and how those updates arrive.

A race condition is not always about which operation finishes first. The more durable idea is that the result depends on relative timing or order. In a last-write-wins example, the final value may be determined by what writes last.

Change the timing, and you may change the result.

* [[workflow|Workflow]] * [[system|System]] * [[current-state|Current State]] * [[duplicate-entry|Duplicate Entry]] * [[manual-reconciliation|Manual Reconciliation]]

* [NIST Special Publication 500-264, *A Taxonomy of Software Security Errors*](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication500-264.pdf) — “Race Conditions,” page 56. * [NIST Special Publication 500-297, *A Data Structure for Software Assurance Assessment Results*](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.500-297.pdf) — race-condition description in the weakness-classification tables.

* [Systems Thinking and AI Engineering](../../../../docs/tracks/systems-thinking-and-ai-engineering.md) * [[workflow|Workflow]]