Question bank — Memory model — happens-before, acquire-release semantics

False. Atomic only stops torn reads of the flag itself; the plain data is ordered solely by the happens-before edge, which needs release/acquire, not mere atomicity. See std-atomic and atomic operations.

True for the atomic itself — relaxed is still atomic, so the atomic never tears — but false for any surrounding non-atomic data, which gets no ordering and races.

False. Acquire is a one-way upward fence: it stops later operations from moving above it. Earlier ops are not its concern.

False. Release is a one-way downward fence: it pins earlier ops above it; later ops may still float up past it.

False. acq_rel only orders memory along a specific synchronizes-with chain. A global total order requires seq_cst; see Sequential consistency vs weak memory models.

False. The edge exists only when the acquire actually reads the released value (or a later value in its release sequence). Reading an older value means the handshake never completed.

True. If $A\stackrel{hb}{\to }B$ and $B\stackrel{hb}{\to }C$ then $A\stackrel{hb}{\to }C$ — that transitivity is exactly what lets a release/acquire pair carry along everything sequenced before it.

False. A happens-before edge orders the two accesses, so it is not a race. Data races require the absence of ordering.

True. Lock acts as acquire, unlock as release, so critical sections publish their writes to the next thread that locks.

True in spirit — it is the safest and the language default — but it is often slower, paying for a global total order with extra fences. Correctness first, then relax deliberately.

False. They are distinct layers: the compiler reorders under the as-if rule at build time; the CPU reorders at run time via out-of-order execution and store buffers. A memory tag must defeat both.

False. The as-if rule guarantees single-thread execution appears in program order; reordering is only observable across threads.

Error: relaxed forms no synchronizes-with edge, so there is no happens-before between data = 42 and the consumer's read — the assert may fire. Use release/acquire.

Error: release is a store ordering; a load cannot be release. A load must use acquire (or relaxed/seq_cst). The compiler will reject or the semantics are meaningless.

Error: a RMW that must both publish prior writes and consume others' writes needs acq_rel. Pure acquire gives no release side, so earlier writes are not pinned above it.

Error: synchronization is about data flow, not wall-clock time. Without the value travelling writer→reader via an atomic, there is no ordering no matter who "ran first".

Error: the final destructor must see all prior threads' writes, which needs an acquire (or acq_rel) on the decrement that reaches zero, else deletion races with those writes.

Error: the loop terminates correctly (relaxed still updates modification order) but forms no hb edge, so the following data read may be stale. The load must be acquire.

Because ordering is carried by data dependency: only when the published value physically travels from writer to reader can the reader inherit the writer's prior work. A different value means it observed a different (or no) publication.

acq_rel only orders along individual synchronizes-with chains; seq_cst additionally forces one global total order all seq_cst ops agree on, defeating the IRIW/Dekker inconsistency that acq_rel permits.

Because acq_rel gives no cross-flag global order — each reader may observe the two stores propagate through caches in a different sequence. Only seq_cst forbids this (the IRIW case).

The standard defines racing accesses as UB so compilers may assume they never happen and optimize freely; once assumed-impossible behavior occurs, any outcome (crash, silent corruption) is permitted.

The compiler may still reorder or cache the plain write under the as-if rule, and portable code must survive weak-memory CPUs. Correctness must come from the model, not from a lucky platform.

A publisher only needs its earlier work pinned below the signal (downward); a subscriber only needs its later reads pinned after seeing the signal (upward). One-way fences are cheaper and exactly sufficient for message passing.

For counters and statistics where only atomicity matters (no surrounding data must be ordered), relaxed avoids fence cost — a staple of Lock-free programming patterns.

No. With no successful read of the stored value, no synchronizes-with edge forms, so nothing is published — the reader would see nothing even if it later stopped.

Full sequenced-before ordering still holds intra-thread — relaxed never weakens single-thread program order; the weakness is purely cross-thread.

Yes — every atomic has a single modification order, so all threads agree on the sequence of writes to that one variable, even under relaxed. What they don't get is ordering of surrounding memory.

On its own, no synchronizes-with edge forms; a standalone fence only helps when paired with a release on the other side and an atomic load/store linking them.

The data no longer races (it is atomic), but the consumer may still read a stale data value because relaxed gives no ordering with the flag — logically wrong, though not UB.

Thread creation establishes a happens-before edge: everything sequenced-before the std::thread construction happens-before the new thread's first operation, so the child sees the parent's prior writes.