Data races: draw the ordering argument

Label each relevant evaluation: writing the payload, publishing readiness, observing readiness, and reading the payload. Within one thread, the specified sequencing supplies edges. Between threads, a suitable synchronization operation supplies an edge only when its requirements are satisfied. Combine those edges transitively to establish happens-before. The graph describes an ordering guarantee, not timestamps collected from the operating system. A sleep, an observed scheduling order, or two log lines appearing in a convenient sequence does not substitute for synchronization.

In the C++ model, conflicting accesses include a write against another read or write of the same memory location; lifetime changes can conflict too. Potentially concurrent conflicting actions create a data race when at least one is non-atomic and neither happens before the other, subject to the standard's special signal-handler rules. A data race yields undefined behavior. Therefore, do not teach an unsynchronized ordinary increment as merely a counter that sometimes loses one update: the language gives no such bounded-result contract.

A producer can initialize an ordinary payload and then perform a release store of true to an atomic ready flag. A worker repeatedly acquire-loads the flag and reads the payload only after observing that publication. Assuming the flag starts false and is not reused, that observation connects the producer's initialization to the read. The payload need not become atomic just because multiple workers read it. It must remain alive and unmodified for the entire period in which those readers may access it.

Reusing the flag changes the problem. A later generation of configuration can overwrite the same payload while a reader still uses the earlier generation, even if every flag access is atomic. Publication alone does not provide exclusion, ownership transfer, or reclamation. Pick an explicit protocol such as locking the full access, publishing independently owned immutable snapshots, or waiting for all prior readers. In C++, volatile supports particular observable-access requirements; it is not the mechanism that makes an ordinary payload safe between threads.

Write an ownership table before changing a memory order: which thread creates, publishes, reads, mutates, and destroys each object? Mark the synchronization object next to every cross-thread handoff. An atomic counter of completed requests may be safely updated with relaxed read-modify-write operations if its value is only a statistic, yet the same counter cannot automatically serve as a publication barrier for request outputs. Whether a value is correct depends on what the program subsequently infers from it.

The network lab shows an actual data dependency in a small computation: a sigmoid reads the weighted input minus one half. Set weight to zero and predict whether changing the input can affect the output; restore weight one and compare. A computation's dependence on a value does not itself establish cross-thread happens-before when another thread supplies that value. The diagram computes one pure scalar function. It contains no threads, synchronization, or publication proof; its graph helps identify consumed values, while the language contract supplies the required ordering edges.