Race condition
A race condition is a concurrency defect in which program behavior or results depend on the relative timing or ordering of interacting operations.
C++ Concurrency in Action, Second Edition
A race condition is a program condition in which behavior depends on the timing or ordering of operations performed by concurrent threads.
- How it is used
- Identifies when thread ordering makes shared-data operations unsafe, especially when an invariant spans multiple steps.
- How deep it goes
- Works through interleaved list and stack operations, then develops mutex and atomic alternatives without detailing the memory model here.
- Examples
- Uses ticket purchases, doubly linked list deletion, interleaved stack calls, lazy initialization, and lock-free stack push.
- What you can do after
- Diagnose/debug with it by checking which interleavings violate invariants, then choose protection covering the complete operation.
Read how C++ Concurrency in Action, Second Edition explains race condition →
Learn Concurrent Programming with Go
A race condition is a concurrency defect in which program behavior depends on the timing or interleaving of unsynchronized operations.
- How it is used
- Frames safe concurrent programming by showing why shared goroutines need synchronization or communication.
- How deep it goes
- Defines timing-dependent failures, traces shared-memory interference, and demonstrates mutex protection; defers broader coordination techniques.
- Examples
- Uses concurrent letter counting, a shared bank balance, scheduler yielding, and an array-update exercise.
- What you can do after
- Diagnose/debug with it by recognizing unsafe shared access and using Go’s race detector or mutex protection.
Read how Learn Concurrent Programming with Go explains race condition →
Learn Go with Pocket-Sized Projects
A race condition is a correctness fault in which the result depends on the timing or interleaving of concurrent operations.
- How it is used
- Flags correctness risks when HTTP requests or maze-search goroutines access shared state concurrently.
- How deep it goes
- Shows mutex-protected reads and writes in a maze solver, while leaving a reliable stopping design unresolved.
- Examples
- Uses concurrent maze explorers writing a solution, HTTP request handlers, and a cache required to be concurrency safe.
- What you can do after
- Diagnose/debug with `go test -race` and protect shared maze-solver state with a mutex.
Read how Learn Go with Pocket-Sized Projects explains race condition →
Python Concurrency with asyncio
A race condition is a concurrency bug in which the result or observable behavior depends on the timing or ordering of concurrent operations.
- How it is used
- Uses race conditions to explain synchronization problems in threads, processes, and asyncio tasks.
- How deep it goes
- Explains timing, non-atomic read-modify-write steps, execution-model differences, and lock-based prevention; it does not develop synchronization internals.
- Examples
- Demonstrates races with reference counts, shared counters, request progress, socket dictionaries, and suspended asyncio tasks.
- What you can do after
- Diagnose/debug timing-dependent shared-state bugs and protect critical sections with the appropriate Python lock.
Read how Python Concurrency with asyncio explains race condition →
Functional Design and Architecture: Examples in Haskell
A race condition is a concurrency defect in which the outcome depends on an unexpected competition between threads for a shared resource.
- How it is used
- Frames the risks of shared mutable state when designing concurrent applications and isolated tests.
- How deep it goes
- Explains interleavings through a meteor-channel failure and contrasts mutexes, concurrent structures, MVar synchronization, and STM transactions.
- Examples
- Uses meteor reporting and parallel tests sharing an IORef to demonstrate lost, duplicated, and order-dependent results.
- What you can do after
- Diagnose/debug with it by recognizing unsafe shared read-modify-write sequences and selecting synchronization or STM-based state updates.
Read how Functional Design and Architecture: Examples in Haskell explains race condition →
Java Persistence with Spring Data and Hibernate epub
A race condition is a correctness problem in which the outcome depends on the timing or interleaving of concurrent operations.
- How it is used
- Identifies a conflict between reading the highest bid and storing a new one.
- How deep it goes
- Works through the bid transaction and its failed commit, including why ordinary Item versioning misses the conflict.
- Examples
- Uses simultaneous auction bids and a JPA transaction that reads the highest bid before persisting another.
- What you can do after
- Apply it via JPA’s OPTIMISTIC_FORCE_INCREMENT lock mode to detect concurrent bid conflicts at commit.
Read how Java Persistence with Spring Data and Hibernate epub explains race condition →
Grokking Concurrency
A race condition is a concurrency bug in which the result depends on the timing or ordering of competing accesses to shared state or resources.
- How it is used
- Identifies timing-dependent failures when concurrent tasks manipulate shared resources such as an account balance.
- How deep it goes
- Works through interleaved balance updates and mutex-protected methods, while treating compiler and hardware reordering conceptually.
- Examples
- Contrasts interleaved ATM deposits, an unexpected balance from Python threads, and a mutex-protected account.
- What you can do after
- Diagnose/debug with it by tracing competing reads and writes, then protect shared balance updates with a common mutex.
Troubleshooting Java, Second Edition
A race condition is a concurrency defect whose outcome depends on the timing or interleaving of operations.
- How it is used
- Uses resource profiling to investigate concurrency failures and distinguish abnormal thread activity from ordinary execution.
- How deep it goes
- Defines the defect, traces a small Java failure, interprets profiler symptoms, and demonstrates synchronization without developing concurrency theory.
- Examples
- Demonstrates competing producers and consumers sharing an ArrayList, runtime exceptions, zombie threads, VisualVM charts, and synchronized replacements.
- What you can do after
- Diagnose with VisualVM and correct shared-list access by synchronizing producer and consumer operations.
Read how Troubleshooting Java, Second Edition explains race condition →
Advanced Algorithms and Data Structures
A race condition is a concurrency error in which program behavior depends on the timing or interleaving of operations.
- How it is used
- Diagnoses timing-dependent failures in shared caches, asynchronous requests, and retailer-order workflows.
- How deep it goes
- Explains execution order, non-atomic cache updates, loading states, polling, subscriptions, and locking, but does not provide a complete solution.
- Examples
- Uses concurrent cache insertion, duplicate sentiment requests, and retailer inventory and delivery decisions.
- What you can do after
- Diagnose interleavings and apply synchronized cache access or in-progress state coordination to reduce inconsistent results and duplicate work.
Read how Advanced Algorithms and Data Structures explains race condition →
Functional Programming in Scala, Second Edition
A race condition is a concurrency defect in which a result depends on the timing or interleaving of operations from multiple threads.
- How it is used
- Diagnoses hazards in non-blocking parallel computations that coordinate results arriving on multiple threads.
- How deep it goes
- Explains the coordination problem and demonstrates an actor-based solution, while deferring detailed actor implementation internals.
- Examples
- Uses Par.map2, two asynchronously arriving results, and an actor that combines stored Option values.
- What you can do after
- Diagnose/debug with actors by identifying arrival-order hazards and serializing coordination through messages.
Read how Functional Programming in Scala, Second Edition explains race condition →
C# Concurrency: Asynchronous and multithreaded programming
A race condition is a concurrent-execution defect in which program results depend on uncontrollable timing or interleaving between execution flows.
- How it is used
- Uses race conditions to diagnose shared-state failures in multithreaded code and establish practical locking rules.
- How deep it goes
- Explains timing-dependent interleavings through C# lock examples, but stops short of memory-model internals or quantitative performance analysis.
- Examples
- Demonstrates separate-lock Add and SetOperands methods whose operations interleave, producing correct, stale, or inconsistent operand results.
- What you can do after
- Diagnose timing-dependent shared-state defects and apply lock scope, lock hierarchy, and callback-safety rules.
Read how C# Concurrency: Asynchronous and multithreaded programming explains race condition →
Go by Example
A race condition is a concurrency defect in which program behavior depends on the timing or ordering of operations accessing shared state.
- How it is used
- Protects shared state and channel lifecycles in concurrent HTTP services, clients, and tests.
- How deep it goes
- Explains race hazards through atomic counters, mutex locking, read/write locking, and safe channel closure.
- Examples
- Uses an HTTP request counter with atomic.Int64, a locked link map, and a dispatcher output channel.
- What you can do after
- Apply it via sync/atomic and sync mutexes to protect counters and in-memory state under concurrent access.
Modern C, Third Edition
A race condition is an execution condition in which the result depends on the relative timing or interleaving of accesses by concurrent or asynchronously executing code.
- How it is used
- Explains how signal handlers and threads make shared-object accesses depend on execution interleaving.
- How deep it goes
- Defines conflicting access, states its failure rule, and introduces atomic indivisibility and linearizability without developing the full memory model.
- Examples
- Uses shared thread state, a _Atomic(bool) termination flag, cursor coordinates, and concurrent atomic operations.
- What you can do after
- Diagnose potentially conflicting accesses and avoid them with atomic objects, while treating atomic_init as a special unsynchronized case.
React Hooks in Action: With Suspense and Concurrent Mode
A race condition is a correctness problem in which the result depends on the timing or ordering of concurrent operations.
- How it is used
- Protects a bookings interface from displaying responses belonging to earlier bookable or week selections.
- How deep it goes
- Explains timing, effect cleanup, response invalidation, and async-await placement, but defers cancelling in-flight requests.
- Examples
- Uses the BookingsGrid, getBookings requests, rapidly changed selections, and a doUpdate cleanup flag.
- What you can do after
- Diagnose stale fetch results and prevent them with useEffect cleanup or correctly nested async functions.
Read how React Hooks in Action: With Suspense and Concurrent Mode explains race condition →
100 Go Mistakes and How to Avoid Them
A race condition is a concurrency defect in which program behavior depends on the timing or ordering of operations on shared state.
- How it is used
- Diagnoses concurrency failures by separating unsafe memory access from behavior that depends on uncontrolled event ordering.
- How deep it goes
- Explains definitions, interleavings, mutex limitations, and coordination remedies, then defers deeper treatment to the Go memory model.
- Examples
- Uses shared increments, interleaving tables, mutex-protected assignments, atomic increments, and channel-coordinated updates.
- What you can do after
- Diagnose nondeterministic concurrent behavior and choose atomic operations, mutexes, or channels according to the required guarantee.
Read how 100 Go Mistakes and How to Avoid Them explains race condition →
Think Distributed Systems
A concurrency situation in which at least one possible ordering of actions produces an incorrect result.
- How it is used
- Explains how concurrent actions and distributed requests can produce incorrect results when their ordering is not controlled.
- How deep it goes
- Defines races with atomic actions and all interleavings, then demonstrates ordering effects with noncommutative operations.
- Examples
- Uses atomic-action interleavings and proposers applying (+2) and (×2) to replicated acceptor state.
- What you can do after
- Evaluate concurrent executions by enumerating possible interleavings and checking whether their results meet the intended correctness condition.
Read how Think Distributed Systems explains race condition →
Rust Servers, Services, and Apps
A race condition is a concurrency defect in which the result depends on the timing or interleaving of operations.
- How it is used
- Explains why multithreaded HTTP request handling requires careful concurrency design.
- How deep it goes
- Defines the defect through a read-update interleaving but does not develop mitigation techniques.
- Examples
- Uses a thread reading memory while another thread updates the same value, alongside multithreaded HTTP request processing.
- What you can do after
- Understand why multithreaded server programs require careful design around shared data and unpredictable execution.
Read how Rust Servers, Services, and Apps explains race condition →
Object-Oriented Software Design in C++
A race condition is a concurrency defect in which program behavior depends on the timing or ordering of simultaneous operations.
- How it is used
- Diagnoses incorrect behavior caused by unsynchronized access to shared resources in multithreaded applications.
- How deep it goes
- Defines the defect and demonstrates singleton creation, while deferring specific avoidance techniques to multithreaded-program design.
- Examples
- Uses simultaneous singleton initialization and concurrent updates to a shared variable as concrete failure cases.
- What you can do after
- Diagnose timing-dependent behavior by identifying unsynchronized access to shared data or resources.
Read how Object-Oriented Software Design in C++ explains race condition →
Go in Practice, Second Edition
A race condition is a correctness or timing defect caused by program behavior depending on the uncontrolled ordering of concurrent operations.
- How it is used
- Uses shared-state failures in concurrent Go programs to motivate mutex protection and race detection.
- How deep it goes
- Explains shared-data timing failures, demonstrates runtime and detector output, and applies sync.Mutex without covering broader synchronization designs.
- Examples
- Demonstrates a concurrent word counter, a concurrent-map runtime failure, race-detector warnings, and a locked implementation.
- What you can do after
- Diagnose/debug with Go's race detector and apply sync.Mutex to protect shared mutable state.
Read how Go in Practice, Second Edition explains race condition →
F# in Action: A Revised Edition of Get Programming with F#
A race condition is a concurrency defect in which a result depends on the timing or interleaving of competing operations.
- How it is used
- Frames concurrency as a practical risk of shared mutable state in multithreaded applications.
- How deep it goes
- Explains the failure scenario and testing difficulty, but does not detail a systematic repair strategy.
- Examples
- Uses a .NET parallel-processing application whose bug appears only under a specific load and message ordering.
- What you can do after
- Diagnose timing-sensitive failures that emerge only under particular concurrent loads or operation orderings.
Read how F# in Action: A Revised Edition of Get Programming with F# explains race condition →
Related concepts
- lockingaddressed by · Locking is a synchronization technique that restricts concurrent access to shared resources or protected operations.
- data raceincludes · A data race is a concurrent access to shared data in which at least one access is a write and the accesses are not adequately synchronized.
- deadlockcontrasts with · A deadlock is a state in concurrent execution where two or more activities are indefinitely blocked by dependencies on resources, events, or progress that cannot become available.
- go testmeasured by · go test is the Go command that builds and runs tests for specified packages and can also execute benchmarks and report coverage.
- double-checked locking patternproduced by · Double-checked locking is a synchronization pattern that checks a shared pointer before and after acquiring a lock to avoid locking when initialization is complete.
- read-modify-write operationproduced by · An operation that reads a value from a location, computes or selects an update, and writes the resulting value back to that location.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.