memory_order_relaxed not work as expected in code from C++ concurrency in action

Question

Before asking this question I tried set my VM cores to more than 1(I set it to 2), according to suggestion from this question, this solution worked for the author, but not for me.

The book C++ Concurrency in Action gives an example in Listing 5.5

#include <atomic>
#include <thread>
#include <assert.h>

std::atomic<bool> x,y;
std::atomic<int> z;

void write_x_then_y()
{
  x.store(true,std::memory_order_relaxed);  // 1
  y.store(true,std::memory_order_relaxed);  // 2
}
void read_y_then_x()
{
  while(!y.load(std::memory_order_relaxed));  // 3
  if(x.load(std::memory_order_relaxed))  // 4
    ++z;
}
int main()
{
    for(int i = 0; i < 1000; i++){
      // this loop is addeed by me in order to try 1000 times to see whether the assertion will fail
      x=false;
      y=false;
      z=0;
      std::thread a(write_x_then_y);
      std::thread b(read_y_then_x);
      a.join();
      b.join();
      assert(z.load()!=0);  // 5
    }
}

The book says the assertion assert(z.load()!=0) may fail. However, I can't fail this assertion when testing.

I tested the program by 64-bit Ubuntu(under VMWare), g++ -g -o test --std=c++17 test.cpp -lpthread, I tested under both gcc 5.4.0 and gcc 7.2.0.

I also tested the program by 64-bit Windows 10(not in a VM), Visual studio 2015.

Meanwhile, by searching the internet, I saw some people say this is because of the x86 architecture, however, I remember in x86, Loads may be reordered with older stores to different locations, so I think there can be a order 2-3-4-1 which can fail this assertion.

1, 2 will not be reordered on x86, unless compiler reorderes them, and they usually don't do this. — , Jan 07 '18 at 17:21
@Ivan So if there's no reordering, then in what situation may the assertion fail? I guess the failure may be associated with CPU's cache line? — calvin, Jan 07 '18 at 17:36
In your example it can't, unless compiler decides to reorder those stores. You might see reordering when there are more than 2 cpus worknig: first cpu sets `x`, second one sets `y`, 3rd one observes `x` changed first, 4rth observes `y` changed first. There is an example at: http://en.cppreference.com/w/cpp/atomic/memory_order under section "Sequentially-consistent ordering" — , Jan 07 '18 at 17:50

score 4 · Accepted Answer · answered Jan 07 '18 at 18:25

The book is correct, the assertion may fail, just not on x86 as you suspected.

To be clear, atomics make the specific guarantee that no data races will occur. It doesn't by itself guarantee absence of race conditions.

std::memory_order_relaxed is the loosest of all memory orders. It is the baseline of everything. In practice, it prevents compiler optimizations around the variables.

atomic<bool> x, y;
x.store(true,std::memory_order_relaxed);
y.store(true,std::memory_order_relaxed);

// is similar to...
volatile bool x, y;
x = true;
asm volatile("" ::: "memory");  // Tells compiler to stop optimizing here,
                                // but issues no instructions
y = true;

However, the CPU might itself decide to reorder the writes or the cache system might decide to publish the write to x some time later. This ultimately leads to the assertion fail.

In terms of the language, this is due to the writes have no happens before relation with the reads and therefore have no guarantees on their results.

Finally, the reason you see no failed assertions on a x86 machine is because it inherently has acquire and release semantics on its reads and writes.

// On x86, effectively
void write_x_then_y()
{
    x.store(true,std::memory_order_release);  // 1
    y.store(true,std::memory_order_release);  // 2
}
void read_y_then_x()
{
    while(!y.load(std::memory_order_acquire));  // 3
    if(x.load(std::memory_order_acquire))  // 4
        ++z;
}

Which is to say, if y is determined to be true at // 3, what happened before //2 is guaranteed to be visible after // 3.

memory_order_relaxed not work as expected in code from C++ concurrency in action

1 Answers1