Code in question:
#include <atomic>
#include <thread>
std::atomic_bool stop(false);
void wait_on_stop() {
while (!stop.load(std::memory_order_relaxed));
}
int main() {
std::thread t(wait_on_stop);
stop.store(true, std::memory_order_relaxed);
t.join();
}
Since std::memory_order_relaxed
is used here, I assume the compiler is free to reorder stop.store()
after t.join()
. As a result, t.join()
would never return. Is this reasoning correct?
If yes, will changing stop.store(true, std::memory_order_relaxed)
to stop.store(true)
solve the issue?
[intro.progress]/18:
An implementation should ensure that the last value (in modification order) assigned by an atomic or synchronization operation will become visible to all other threads in a finite period of time.
[atomics.order]/12:
Implementations should make atomic stores visible to atomic loads within a reasonable amount of time.
This is a non-binding recommendation. If your implementation follows them - as high-quality implementations should - you are fine. Otherwise, you are screwed. In both cases regardless of the memory order used.
The C++ abstract machine has no concept of "reordering". In the abstract semantics, the main thread stored into the atomic and then blocked, and so if the implementation makes the store visible to loads within a finite amount of time, then the other thread will load this stored value within a finite amount of time and terminate. Conversely, if the implementation doesn't do so for whatever reason, then your other thread will loop forever. The memory order used is irrelevant.
I've never found reasoning about "reordering" to be useful. It mixes up low-level implementation detail with a high-level memory model, and tends to make things more confusing, not less.