C++ Atomic variable visibilty

Question

#include <atomic>

std::atomic<int> foo;

void ThreadA()
{
    foo.store(1, std::memory_order_relaxed);

    while (true) {};
}

void ThreadB()
{
    while (foo.load(std::memory_order_relaxed) == 0)
    {
    }
}

For atomic variables that use relaxed operations, is it theoretically possible that thread B will never be able to read the latest value of the foo variable (assuming that there is no interference from other threads refreshing the cache)?

Or do we have any guarantee, whether it is hardware, operating system, or C++ standard, thread B can read the latest foo variable value in a finite time?

Answer 1

This has been effectively guaranteed since C++11, with all quotes from the C++20 standard. First there is [intro.races]/4 wihch states

All modifications to a particular atomic object M occur in some particular total order, called the modification order of M.

and then later on, in paragraphs 15 to 19

15. If an operation A that modifies an atomic object M happens before an operation B that modifies M, then A shall be earlier than B in the modification order of M. [Note 15: This requirement is known as write-write coherence. — end note]

16. If a value computation A of an atomic object M happens before a value computation B of M, and A takes its value from a side effect X on M, then the value computed by B shall either be the value stored by X or the value stored by a side effect Y on M, where Y follows X in the modification order of M. [Note 16: This requirement is known as read-read coherence. — end note]

17. If a value computation A of an atomic object M happens before an operation B that modifies M, then A shall take its value from a side effect X on M, where X precedes B in the modification order of M. [Note 17: This requirement is known as read-write coherence. — end note]

18. If a side effect X on an atomic object M happens before a value computation B of M, then the evaluation B shall take its value from X or from a side effect Y that follows X in the modification order of M. [Note 18: This requirement is known as write-read coherence. — end note]

19. [Note 19: The four preceding coherence requirements effectively disallow compiler reordering of atomic operations to a single object, even if both operations are relaxed loads. This effectively makes the cache coherence guarantee provided by most hardware available to C++ atomic operations. — end note]

With the note in paragraph 19 summarizing it best: The four preceding coherence requirements effectively disallow compiler reordering of atomic operations to a single object, even if both operations are relaxed loads.

Answer 2

Presuming that ThreadA() and ThreadB() are actually executed concurrently in the first place, then the C++ standard would indeed theoretically guarantee that ThreadB() will eventially read the change to the atomic and terminate properly.

In reality, things can get a bit more messy. I can think of three scenarios where ThreadB() will never see the change to the atomic:

1. Something outside of threads A and B terminates thread B prematurely, or stalls it indefinitely. Then obviously it can't get to the point where it sees the change.

2. Something outside of threads A and B terminates thread A prematurely, or stalls it indefinitely. Then obviously it can't get its message out, and thread B will never see it.

3. Something outside of threads A and B disrupts communication between whatever hardware entities are running the respective threads.

3 is, fortunately, a rather hypothetical scenario for pieces of software, but in e.g. a supercomputer environment, I can imagine that it may be worth hardening software against such scenarios if they cannot be robustly handled at a hardware level.

1 and 2 may actually happen even on single-core machines. For instance, the user might pause the program using a debugger, suspend one thread, unpause the others, and then walk away from the keyboard to buy a pack of cigarettes, never to return. Or maybe some anti-virus software goes haywire and decides that thread A is a security threat, and that it needs to be terminated, but for some obscure reason does not terminate thread B.

This may sound trivial, but in a more problematic variant of scenario 2, maybe something in your program causes the operating system to run low on resources until thread B completes. Then the lack of resources could potentially cause the operating system to stall thread A because it thinks it has more important tasks to throw its sparse resources at, which in turn would prevent the operating system to recover.

(A similar thing might conceivably happen with scenario 1, though it is a bit more boring.)

None of these scenarios are sensitive to the memory order though.

Answer 3

Under normal conditions, the operating system will make sure that each thread gets its fair share of CPU time. This means that yes, barring exceptional circumstances in which you'd probably have other worries, thread B will eventually get a chance to read the change to the atomic variable. This is regardless of memory order.

It is also guaranteed by the C++ standard that thread B will read the atomic variable over and over again (as opposed to just read it once and cache the result) until the change to the atomic value has been submitted by thread A and propagated to whatever entity is executing thread B. Again, regardless of memory order.