Atomics: indivisibility is only one guarantee

An atomic load followed by an atomic store is not the same operation as fetch-add. With a load and store, two threads can read the same old count and both write the same incremented value. The accesses themselves remain atomic, so this example can be data-race-free while its counting behavior is incorrect. An atomic read-modify-write obtains the immediately preceding value in that atomic object's modification order and writes its update as one operation, preventing that lost increment for the counter.

Relaxed fetch-add can be sufficient for a statistic when no other memory is published or consumed based on the count. It preserves atomicity and the relevant per-object ordering rules without providing a release/acquire synchronization edge for unrelated payloads. If a reader needs an exact final count, specify how it waits for all contributors to finish, for example by joining them before loading. Mid-execution observations do not imply all workers have finished their surrounding work.

Release/acquire is useful for a directed handoff. A producer initializes a payload before its release store; a consumer that acquire-loads the corresponding published value can use the resulting synchronizes-with edge. An acquire operation does not magically collect every write made by every thread. The value it observes, its associated release or release sequence, and the surrounding sequencing determine the actual relation. A protocol involving repeated values or reused storage needs more reasoning than the simple one-shot flag.

Sequentially consistent atomics additionally participate in a specified total order for those operations. This is often a good starting point for an algorithm, but it does not make a pair of loads a snapshot or serialize whole methods. Mixing weaker operations changes what can be inferred. Invariants such as balance-plus-reservation consistency usually need a lock, a suitable combined atomic state, or a separately proved protocol. Never repair a multi-object invariant merely by attaching the strongest label to each independent field.

A memory-order change must identify which required edges remain and which previously allowed outcomes now matter. Check the exact C++ version's operation constraints, and avoid copying assembly intuition into a portable language argument. The atomic type's lock-free property depends on its type and implementation; using std::atomic does not universally establish a lock-free algorithm. Even a lock-free primitive can sit inside a method that allocates, blocks, retries indefinitely for one thread, or invokes arbitrary user code.

The probability lab helps separate a statistical claim from a correctness guarantee. For fixed trial count, increase success probability and predict the changed mean and variance of the exact binomial distribution. Then ask why an unobserved failure in many test runs is still not a memory-model proof: executions need not be independent trials with a fixed failure probability. The lab does not execute atomic instructions or estimate their correctness. Use it to question the sampling assumption before quoting a reliability percentage from stress tests.