Data Races And Memory Models

What A Data Race Is

A data race usually means that multiple concurrent execution contexts access the same memory location, at least one access writes, and the accesses are not ordered by synchronization. The exact definition is language-specific, but the risk is shared: the program can observe behavior that does not match ordinary sequential reasoning.

Memory models describe what reads and writes are allowed to observe, which operations synchronize with each other, and how compilers and processors may reorder work. They exist because modern hardware and optimizing compilers do not execute every memory operation in the simple order source code suggests.

Why It Matters

Without a memory model, concurrent code cannot reliably say when one task sees another task's write. Locks, atomics, channels, thread joins, volatile-like operations, and runtime synchronization APIs matter because they establish ordering and visibility guarantees.

Different languages make different promises. Go documents synchronization through channels, mutexes, atomics, and other operations. Java specifies happens-before relationships. Rust treats data races as outside safe Rust and uses ownership plus synchronization traits to constrain sharing.

Watch Points

"It worked in testing" is weak evidence for race freedom. Races may depend on CPU architecture, compiler version, optimization level, runtime scheduler, workload, and timing. Use race detectors, sanitizers, model-aware APIs, immutable data, message passing, and code review focused on shared state.

Related Concepts

Read data races with Threads And Shared Memory, Memory Safety, Ownership, Actor Model And Message Passing, and Testing Cultures.