Question Details

No question body available.

Tags

c++ c++11 memory-barriers stdatomic happens-before

Answers (7)

April 1, 2026 Score: 3 Rep: 129,209 Quality: Low Completeness: 0%

This shouldnt be an Advice question. You ask plain yes/no questions without room for opinions or openended discussions. Though, there is no way to migrate or change the type of the question :/

April 1, 2026 Score: 2 Rep: 53,226 Quality: Medium Completeness: 60%

Sequenced-before is a relationship between evaluations on the same thread. Memory order affects visibilty of the effects of evaluations in a different thread, as well as data races. There isn't a single, program-wide order of evaluation when multiple threads are involved - individual threads' timelines cannot generally be combined into a single timeline.

For example, one thread may observe modifications performed by another thread out of order - observe the new value for the variable assigned later while the old value for the variable assigned earlier (where "later" means "sequenced-after on the thread that actually performed the assignments").

In your example, the compiler or the CPU may reorder C and D under the As-If rule; it's a permitted optimization because a conforming program cannot tell the difference. Recall that the C++ standard doesn't specify the exact machine code to be generated, or how that code must be executed by the hardware. Rather, it describes a non-deterministic abstract machine, and only requires that a conforming implementation produce the same observable side effects as one possible execution of that abstract machine.

The only side effect of C is assignment to r2. Nothing interesting depends on when exactly that happens, so this whole "initiation vs completion" line of reasoning is kinda moot. This is not what memory order is about.


Note also that the C++ standard before C++11 didn't have any concept of threads or atomics, and was silent about multi-threading. You seem to ascribe some deep thread-related meaning to the change from "sequence point" to "sequenced-before" terminology - that had nothing to do with threads. Rather, it was discovered that the concept of "sequence point" was under-specified. Consider (a=1, b=2) + (c=3, d=4) - where are the sequence points in this expression? (Recall that operands of a comma operator must be sequenced left to right, but operands of + operator can be evaluated in either order.)

April 1, 2026 Score: 2 Rep: 77,269 Quality: Low Completeness: 10%

Minor point: "sequence point" to "sequenced-before" was precisely to accommodate threading. But the change was purely to terminology: it did not (was not supposed to, I suppose) affect the meaning of any valid pre-C++11 program.

April 1, 2026 Score: 1 Rep: 230,049 Quality: Low Completeness: 0%

Pre-C++11, threading was not in standard, so the guarantees come from elsewhere (compiler/libraries/...).

April 1, 2026 Score: 0 Rep: 1 Quality: Low Completeness: 0%

unfortunately yes, however i need advise on my confusion about interpreting the standard

April 1, 2026 Score: 0 Rep: 1 Quality: Low Completeness: 70%

In fact my above question is not about memory order or MT programming, the example is from memory order page of cppreference just because the C vs D issue is explicitly stated by the standard there.

But my initial confusion originated from visibility of atomic variables. Here is the story:

From https://en.cppreference.com/w/cpp/atomic/memoryorder.html

Visible side-effects

The side-effect A on a scalar M (a write) is visible with respect to value computation B on M (a read) if both of the following are true:

  1. A happens-before B.
  2. There is no other side effect X to M where A happens-before X and X happens-before B.

Happens-before

Regardless of threads, evaluation A happens-before evaluation B if any of the following is true:

  1. A is sequenced-before B.
  2. A inter-thread happens before B.

Inter-thread happens-before

Between threads, evaluation A inter-thread happens before evaluation B if any of the following is true:

  1. A synchronizes-with B. (i skipped the rest)

The inter-thread happens-before is clear to me. Thread X does store-release, thread Y does load-acquire, if Y reads the value written by X, then X synchronizes-with Y.

That same clarity does not exist for the load / store within the same thread, putting all together the above definitions, it seems that A is sequenced-before B satisfies the side-effect visibility condition, i.e. if A is sequenced-before B then the side effects of A are visible to B. But the sequence-before explanation itself rejects this (or at least i thought so, which is the root cause for the completion / initiation issue).

It would be better to ask this in a separate question, but anyways, maybe this helps to better explain myself.

April 1, 2026 Score: 0 Rep: 611,954 Quality: Low Completeness: 30%

Isn't that what the tag is meant for?