Is it necessery to use atomic_int but not only plain int as critical data between threads?

Question

I am reading the book of CPP-Concurrency-In-Action-2ed-2019. In chapter 5.3, the author gives a simple example:

#include <vector>
#include <atomic>
#include <iostream>

std::vector<int> data;
std::atomic<bool> data_ready(false);

void reader_thread()
{
  while(!data_ready.load())  // 1
  {
    std::this_thread::sleep(std::milliseconds(1));
  }
  std::cout<<"The answer="<<data[0]<<"\m";  // 2
}
void writer_thread()
{
  data.push_back(42);  // 3
  data_ready=true;  // 4
}

Althought the author only wants to explain how to use atomic_bool to control code sequences(i.e syncronization) between threads.But what confuses me is that if I use plain bool instead of atomic_bool, isn't it still thread-safe?

#include <vector>
#include <atomic>
#include <iostream>

std::vector<int> data;
bool data_ready(false);

void reader_thread()
{
  while(!data_ready)  // 1
  {
    std::this_thread::sleep(std::milliseconds(1));
  }
  std::cout<<"The answer="<<data[0]<<"\m";  // 2
}
void writer_thread()
{
  data.push_back(42);  // 3
  data_ready=true;  // 4
}

Such as +=, -=, *=, |= are not thread-safe, I know that, but only write/read on a POD variable isn't originally thread-safe itself, such as data_ready=true?

I also search for other answers like Difference between atomic and int, but to be honest, I don't get their point~~

Answer 1

You cannot use a plain bool for inter-thread communication, because it can lead to a data race. A data race in C++ occurs when two threads access the same memory simultaneously, and at least one of these accesses is a write. Formally:

The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below. Any such data race results in undefined behavior.

Two expression evaluations conflict if one of them modifies a memory location and the other one reads or modifies the same memory location.

- [intro.races]/21, [intro.races]/2

Consider what can happen:

// reader thread reads
while(!data_ready)

// writer thread writes
data_ready = true;

There is no synchronization that prevents these accesses from happening concurrently, making it a data race.

Even without a data race, compilers may optimize non-atomic objects much more aggressively. while(!data_ready) {} is either:

• a no-op, if data_ready == true (OK), or
• an infinite loop (UB), if data_ready == false, and we assume that data_ready isn't updated by another thread.

Technically, using std::atomic in this way is also not okay, because the compiler isn't forbidden from assuming that data_ready never changes, even if it is atomic. This code relies on the mantra "no sane compiler would optimize atomics".

Behavior for various architectures in practice

x86_64

You might not experience any symptoms of this UB because on x86_64, all aligned memory access up to 8 bytes is atomic anyway. However, you shouldn't rely on the architecture making this "okay in practice", and always use atomics.

As stated above, the code is also more likely to get stuck in an infinite loop due to compiler optimizations, regardless of whether there is a data race.

Others

On other architectures, it might be possible that !data_ready will read a nonsense value if another thread is writing to data_ready at the same time. This may be unlikely for something small like bool, but very likely for larger types like char[1024], which are also POD/trivially copyable, but cannot be written to memory in one operation.