Chapter 21: Atomic access and memory consistency

Introduction

The introduction frames memory consistency in terms of concurrent access, effects on a program’s abstract state, and the limits of a single timeline across threads.

• Concurrent access and visibility: Distinguish the visibility and consistency concerns raised by ordinary C execution, atomic objects, and threads, and name the synchronization examples given here.
  Why it matters: These distinctions explain why reasoning about shared data requires more than reading statements in source order.
• Abstract state and effects: Describe the components of a program execution’s abstract state and explain why the section calls every evaluation an effect.
  Why it matters: It gives you a broader way to describe what execution changes besides writes to memory.
• No shared thread timeline: Explain why the introduction avoids assuming one fine-grained time or fully observable overall state for a multithreaded execution.
  Why it matters: It cautions against reasoning about concurrent execution as though all threads shared one precise clock.

Key terms: sequence points, atomic objects, threads, synchronization, abstract state, effect, points of execution, intermediate values, stored values, hidden state

21.1 The “happened-before” relation

Explains how sequencing within threads and synchronization between threads establish happened-before relationships that make effects visible across threads.

• Happened-before chains: Explain how sequenced-before and synchronizes-with relationships combine to establish that one evaluation happened before another.
  Why it matters: The chain gives you a basis for saying which events are ordered, even when they occur in different threads.
• Atomic modification order: Describe the modification order of an atomic object and how it relates to the order of operations in threads that use that object.
  Why it matters: It lets you reason about changes to a shared atomic object without losing the ordering imposed within each thread.
• Acquire-release synchronization: Explain when an atomic read synchronizes with a write in another thread, including the two sides of a read-modify-write operation.
  Why it matters: Reading the written value is what establishes the cross-thread link; using the same atomic object alone is not enough.
• Visibility across synchronization: Trace how effects made before a release become visible after a matching acquire, using the section’s atomic examples.
  Why it matters: This is how reasoning about an atomic exchange helps establish what one thread can observe of another thread’s earlier work.

Key terms: happened-before relation, sequenced-before relation, synchronizes-with relation, transitive closure, atomic object, modification order, acquire semantics, release semantics, read-modify-write operations, synchronizes with

21.2 C library calls that provide synchronization

This section explains how C library calls synchronize threads through release and acquire operations, making earlier effects visible to later operations.

• Thread creation and joining: Explain what synchronization through thrd_create and thrd_join establishes, particularly what the joining thread can observe after joining its threads.
  Why it matters: Joining threads provides a basis for using their completed work.
• One-time initialization visibility: Explain how call_once makes initialization performed by its callback visible to other threads calling it with the same object.
  Why it matters: It explains why threads can safely use an object after passing its one-time initialization call.
• Mutex critical-section visibility: Explain why critical sections protected by the same mutex occur sequentially and why a later section sees effects of earlier ones.
  Why it matters: A mutex protects shared data by making one protected update visible to the next holder.
• Condition-wait mutex handoff: Describe the release and acquire operations performed by cnd_wait and cnd_timedwait and identify where their synchronization occurs.
  Why it matters: The wait operation’s mutex handoff determines which shared changes a returning waiter can rely on.
• Condition-signal placement: Justify placing cnd_signal or cnd_broadcast inside a critical section protected by the waiters’ mutex when signaling changes to non-atomic shared data.
  Why it matters: Waking a thread is not, by itself, enough to ensure it sees non-atomic changes to the condition it checks.

Key terms: thrd_create, thrd_join, thrd_exit, release, acquire, call_once, release operation, acquire operation, errlog, mutex

21.3 Sequential consistency

The section explains the global ordering required by sequential consistency, the default consistency of atomic operators and interfaces, and the exception for atomic_init.

• Global sequential ordering: Explain how sequential consistency orders atomic operations across different objects and how it strengthens acquire-release consistency.
  Why it matters: This stronger ordering can constrain parallel execution of atomic accesses.
• Default atomic interface behavior: State the default consistency of atomic operators and functional interfaces, and distinguish a fetch-and-operator return value from a compound assignment result.
  Why it matters: The default ordering and the returned value both affect how an atomic expression behaves.
• Atomic initialization exception: Distinguish atomic_init from synchronizing atomic operations, including the consequence of concurrent calls.
  Why it matters: An initialization call should not be mistaken for a way to synchronize threads.

Key terms: sequential consistency, acquire-release consistency, global modification order, functional interfaces, fetch and operator interfaces, compound assignment operator, atomic_init, synchronization, race

21.4 Other consistency models

This section explains how C’s explicit atomic interfaces select memory consistency orders, which orders fit particular operations, and why consume ordering exists.

• Explicit atomic memory orders: Explain how an atomic operation’s _explicit interface uses a memory_order argument and how that compares with the interface without _explicit.
  Why it matters: It lets you recognize where an atomic operation’s consistency requirements are specified.
• Orders and typical operations: Distinguish the ordering roles and typical uses of acquire-release, release, acquire, and relaxed atomic operations.
  Why it matters: The operation’s role determines which synchronization requirements are useful.
• Operation-specific ordering limits: Explain why stores, loads, and failed compare-exchanges have different allowed orders, including the two orders supplied to explicit compare-exchange.
  Why it matters: These limits prevent requesting synchronization semantics that an operation cannot perform.
• Consume ordering motivation: Explain the limited motivation given for consume consistency and the caution about using it.
  Why it matters: It explains why consume exists without suggesting that its detailed behavior was covered here.

Key terms: _explicit, memory_order, memory_order_seq_cst, memory_order_acq_rel, memory_order_release, memory_order_acquire, memory_order_relaxed, read-modify-write, atomic_store, atomic_flag_clear

21.5 Summary