Data-race freedom by construction¶
Category: Safety in languages · Status: stub · Lessons: chapter 02, Shared state
One line: A language rule that makes data races impossible to write in the first place — Rust's ownership with Send and Sync, or actors that never share memory.
How it connects¶
flowchart LR
n_data_race["Data race"]
n_data_race_freedom["Data-race freedom by construction"]
n_send_and_sync["Send and Sync"]
n_data_race_freedom -->|prevents| n_data_race
n_data_race_freedom -->|uses| n_send_and_sync
classDef center stroke-width:3px
class n_data_race_freedom center
classDef outside stroke-dasharray: 4 3
class n_data_race,n_send_and_sync outside
- Is built on: Send and Sync
- Helps prevent: Data race
In each language¶
| Rust | The Rustonomicon ↗: safe Rust guarantees an absence of data races, though not of race conditions |
| Go | A convention, not a rule: Effective Go ↗ says share memory by communicating, so only one goroutine has access to a value at a time |
| JavaScript | Web workers ↗ exchange messages whose data is copied rather than shared |
| Swift | The Swift 6 language mode ↗ prevents data races at compile time |
| Erlang and Elixir | All data in messages between processes is copied ↗, except refc binaries and literals |
Where to read more¶
- In this library: Is total += n safe on two threads?
- In the books: Rust Atomics and Locks, Mara Bos — ch. 1, 'Basics of Rust Concurrency' → 'Borrowing and Data Races'
- In the books: The Rust Programming Language, Steve Klabnik, Carol Nichols — ch. 16, 'Fearless Concurrency'
- In the books: Rust for Rustaceans, Jon Gjengset — ch. 10, 'Concurrency (and Parallelism)' → 'Sane Concurrency'
- Notes: data race freedom (DRF) ↗