liveBook · Manning

Race condition

As explained in 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.

A race condition occurs when concurrent goroutines access changing shared data and correctness depends on their uncontrolled ordering. Partial updates or out-of-order mutations can corrupt data or produce runtime errors. section 5.2.2

Recognize and contain the problem by:

  • Identifying shared mutable state accessed by multiple goroutines. section 5.2.2
  • Protecting the shared resource with sync.Mutex, then unlocking it after use. section 5.2.2

Concurrent word counter

A word-counting tool processes multiple files in separate goroutines while updating one map. Without protection it can fail with “concurrent map writes”; locking the words structure serializes access.

How Go in Practice, Second Edition covers it

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 it assumes
Assumes familiarity with goroutines and shared data while introducing race conditions, mutex locking, and race-detector use.
What you can do after
Diagnose/debug with Go's race detector and apply sync.Mutex to protect shared mutable state.
How it connects
Connects race conditions with goroutines, shared mutable data, maps, sync.Mutex, and the Go race detector.

Also explained in

Compare how 20 books explain race condition →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Go in Practice, Second Edition. The section links point to the parts of the book it draws on.