std::call_once safe for non atomic variables?

Question

Will std::call_once work properly for non-atomic variables? Consider the following code

std::once_flag once;
int x;

void init() { x = 10; }

void f() {
  std::call_once(once, init);
  assert(x == 10);
}

int main() {
  std::thread t1(f), t2(f);
  t1.join();
  t2.join();
}

Will the side-effect in init be seen to all threads when call_once returns? Documentation on cppreference is kind of vague. It only says on all threads std::call_once will return after init is completed, but doesn't mention anything that prevents the x=10 being reordered after init returns.

Any ideas? Where in the standard that clarifies the behavior?

Answer 1

Will the side-effect in init be seen to all threads when call_once returns?

Side effects from init are visible to all threads that have called call_once There is no more than one active execution (calling init) but multiple passive executions are possible.

§ 30.4.6.2-2 - [thread.once.callonce]

An execution of call_once that does not call its func is a passive execution. An execution of call_once that calls its func is an active execution.

§ 30.4.6.2-3 - [thread.once.callonce]

Synchronization: For any given once_flag: all active executions occur in a total order; completion of an active execution synchronizes with (6.8.2) the start of the next one in this total order; and the returning execution synchronizes with the return from all passive executions.

So it is exactly as you expected

Answer 2

The main difference between atomic and non-atomic variables is that access to a non-atomic variable from multiple threads (unless all threads are reading) needs explicit synchronization to prevent the accesses from being potentially concurrent.

There are various ways to achieve this synchronization. The most common technique involves mutexes. The unlocking of a mutex by one thread synchronizes with the subsequent locking of that mutex by another thread. Thus, if the first thread writes a variable and the second thread reads that variable, an explicit ordering exists between the write and the read. The program then behaves as you expect: the read must see the last value written in that ordering. If mutexes were not used, the accesses to the variable would be potentially concurrent, and undefined behaviour would occur.

Atomic variables are self-synchronizing: no matter what, two threads attempting to access the same atomic variable will work out some order between them. Besides that, they don't have any special ability, compared to non-atomic variables, to be accessed by multiple threads.

The use of std::call_once with the same flag by multiple threads sets up an explicit synchronization: each thread only returns from std::call_once once init has completed, so each thread must see the new value of x.

The compiler is only allowed to reorder writes to the extent that it does not alter the observable behaviour of the program. Race conditions that you rationalize in terms of reordering disappear once you adhere to the standard by not allowing writes to a non-atomic variable to be potentially concurrent with another access to the same variable.