stdatomic

On the x86 architecture, stores to the same memory location have a total order, e.g., see this video . What are the guarantees in the C++11 memory model? More precisely, in -- Initially -- std::atomic<int> x{0}; -- Thread 1 -- x.store(1, std::memory_order_release); -- Thread 2 -- x.store(2, std::memory_order_release); -- Thread 3 -- int r1 = x.load(std::memory_order_acquire); int r2 = x.load(std::memory_order_acquire); -- Thread 4 -- int r3 = x.load(std::memory_order_acquire); int r4 = x.load(std::memory_order_acquire); would the outcome r1==1, r2==2, r3==2, r4==1 be allowed (on some

If a data structure has multiple elements in it, the atomic version of it cannot (always) be lock-free. I was told that this is true for larger types because the CPU can not atomically change the data without using some sort of lock. for example: #include <iostream> #include <atomic> struct foo { double a; double b; }; std::atomic<foo> var; int main() { std::cout << var.is_lock_free() << std::endl; std::cout << sizeof(foo) << std::endl; std::cout << sizeof(var) << std::endl; } the output (Linux/gcc) is: 0 16 16 Since the atomic and foo are the same size, I don't think a lock is stored in the

This question already has an answer here: Can a bool read/write operation be not atomic on x86? [duplicate] 3 answers Do I have to use atomic<bool> for “exit” bool variable? 3 answers Isn't atomic<bool> redundant because bool is atomic by nature? I don't think it's possible to have a partially modified bool value. When do I really need to use atomic<bool> instead of bool ? No type in C++ is "atomic by nature" unless it is an std::atomic* -something. That's because the standard says so. In practice, the actual hardware instructions that are emitted to manipulate an std::atomic<bool> may (or may

I have something like: if (f = acquire_load() == ) { ... use Foo } and: auto f = new Foo(); release_store(f) You could easily imagine an implementation of acquire_load and release_store that uses atomic with load(memory_order_acquire) and store(memory_order_release). But now what if release_store is implemented with _mm_stream_si64, a non-temporal write, which is not ordered with respect to other stores on x64? How to get the same semantics? I think the following is the minimum required: atomic<Foo*> gFoo; Foo* acquire_load() { return gFoo.load(memory_order_relaxed); } void release_store(Foo*

Similar to my previous question, consider this code -- Initially -- std::atomic<int> x{0}; std::atomic<int> y{0}; -- Thread 1 -- x.store(1, std::memory_order_release); -- Thread 2 -- y.store(2, std::memory_order_release); -- Thread 3 -- int r1 = x.load(std::memory_order_acquire); // x first int r2 = y.load(std::memory_order_acquire); -- Thread 4 -- int r3 = y.load(std::memory_order_acquire); // y first int r4 = x.load(std::memory_order_acquire); Is the weird outcome r1==1, r2==0 and r3==2, r4==0 possible in this case under the C++11 memory model? What if I were to replace all std::memory_order