stdatomic

sorry for the verbosity - I did my best to condense my code sample into a minimally functional class and main() method. I'm trying to use an atomic_flag to notify _rx() within my worker thread to quit when stop() is called. I believe the issue is in trying to create my worker thread, thread SanityTestThread(&SanityTest::_rx, *this); which somehow clashes with my atomic_flag code sample (does not compile): #include <cstdio> #include <chrono> #include <unistd.h> #include <atomic> #include <iostream> #include <thread> using namespace std; class SanityTest { public: SanityTest(){} void start();

I see that g++ generates a simple mov for x.load() and mov + mfence for x.store(y) . Consider this classic example: #include<atomic> #include<thread> std::atomic<bool> x,y; bool r1; bool r2; void go1(){ x.store(true); } void go2(){ y.store(true); } bool go3(){ bool a=x.load(); bool b=y.load(); r1 = a && !b; } bool go4(){ bool b=y.load(); bool a=x.load(); r2= b && !a; } int main() { std::thread t1(go1); std::thread t2(go2); std::thread t3(go3); std::thread t4(go4); t1.join(); t2.join(); t3.join(); t4.join(); return r1*2 + r2; } in which according to https://godbolt.org/z/APS4ZY go1 and go2 are

I am currently reading C++ Concurrency in Action by Anthony Williams. One of his listing shows this code, and he states that the assertion that z != 0 can fire. #include <atomic> #include <thread> #include <assert.h> std::atomic<bool> x,y; std::atomic<int> z; void write_x() { x.store(true,std::memory_order_release); } void write_y() { y.store(true,std::memory_order_release); } void read_x_then_y() { while(!x.load(std::memory_order_acquire)); if(y.load(std::memory_order_acquire)) ++z; } void read_y_then_x() { while(!y.load(std::memory_order_acquire)); if(x.load(std::memory_order_acquire)) ++z;

In 29.5 Atomic types of the C++ Standard November 2014 working draft it states: There is a generic class template atomic. The type of the template argument T shall be trivially copyable (3.9). [ Note: Type arguments that are not also statically initializable may be difficult to use. —end note ] So - as far as I can tell - this: #include <atomic> struct Message { unsigned long int a; unsigned long int b; }; std::atomic<Message> sharedState; int main() { Message tmp{1,2}; sharedState.store(tmp); Message tmp2=sharedState.load(); } should be perfectly valid standard c++14 (and also c++11) code.

Why is std::atomic 's store : std::atomic<int> my_atomic; my_atomic.store(1, std::memory_order_seq_cst); doing an xchg when a store with sequential consistency is requested? Shouldn't, technically, a normal store with a read/write memory barrier be enough? Equivalent to: _ReadWriteBarrier(); // Or `asm volatile("" ::: "memory");` for gcc/clang my_atomic.store(1, std::memory_order_acquire); I'm explicitly talking about x86 & x86_64. Where a store has an implicit acquire fence. mov -store + mfence and xchg are both valid ways to implement a sequential-consistency store on x86. The implicit lock