stdatomic

问题 I have a question regarding a GCC-Wiki article. Under the headline "Overall Summary" the following code example is given: Thread 1: y.store (20); x.store (10); Thread 2: if (x.load() == 10) { assert (y.load() == 20) y.store (10) } It is said that, if all stores are release and all loads are acquire , the assert in thread 2 cannot fail. This is clear to me (because the store to x in thread 1 synchronizes with the load from x in thread 2). But now comes the part that I don't understand. It is

问题 I want to use an std::atomic_int variable. In my code, I have: #include <atomic> std::atomic_int stop = 0; int main() { // Do something } And this gives me a compile error: use of deleted function 'std::__atomic_base<_IntTp>::__atomic_base(const std::__atomic_base<_IntTp>&) [with _ITp = int]' std::atomic_int stop = 0; ^ Any idea on what's going on? 回答1: Your code is attempting to construct a temporary std::atomic_int on the RHS, then use the std::atomic_int copy constructor (which is delete d

问题 My question is quite simple. Why isn't std::atomic<double> implemented completely? I know it has to do with atomic RMW (read-modify-write) access. But I really don't see, why this shouldn't be possible on a double . It's specified that any trivially copyable type can be used. And of course double is among them. So C++11 requires the basic operations (load, store, CAS, exchange, etc.) that you can use with any class type. However, on integers an extra set of operations is possible ( fetch_add

问题 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. 回答1: mov -store +

问题 From C++ Concurrency in Action: difference between std::atomic and std::atomic_flag is that std::atomic may not be lock-free; the implementation may have to acquire a mutex internally in order to ensure the atomicity of the operations I wonder why. If atomic_flag is guaranteed to be lock-free, why isn't it guaranteed for atomic<bool> as well? Is this because of the member function compare_exchange_weak ? I know that some machines lack a single compare-and-exchange instruction, is that the

问题 Can anyone explain what is std::memory_order in plain English, and how to use them with std::atomic<> ? I found the reference and few examples here, but don't understand at all. http://en.cppreference.com/w/cpp/atomic/memory_order 回答1: Can anyone explain what is std::memory_order in plain English, The best "Plain English" explanation I've found for the various memory orderings is Bartoz Milewski's article on relaxed atomics: http://bartoszmilewski.com/2008/12/01/c-atomics-and-memory-ordering/

问题 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

问题 I recently upgraded to a C++11 compatible compiler, and I was trying to update some code from boost to c++11 standards. I ran into a problem when converting some code using atomic_store over. Here is some simple test code that seems to be throwing a compiler error for me. int main() { std::shared_ptr<int> m = std::make_shared<int>(); *m = 1; std::shared_ptr<int> a = std::make_shared<int>(); *a = 2; std::atomic_store(&m,std::move(a)); std::cout << *m << std::endl; } the std::atomic_store(&m

问题 To be precise, I only need to increase a double by another double and want it to be thread safe. I don't want to use mutex for that since the execution speed would dramatically decrease. 回答1: As a rule, the C++ standard library tries to provide only operations that can be implemented efficiently. For std::atomic , that means operations that can be performed lock-free in an instruction or two on "common" architectures. "Common" architectures have atomic fetch-and-add instructions for integers,

问题 I have been stepping through the function calls that are involved when I assign to an atomic_long type on VS2017 with a 64bit project. I specifically wanted to see what happens when I copy an atomic_long into a none-atomic variable, and if there is any locking around it. atomic_long ll = 10; long t2 = ll; Ultimately it ends up with this call (I've removed some code that was ifdef ed out) inline _Uint4_t _Load_seq_cst_4(volatile _Uint4_t *_Tgt) { /* load from *_Tgt atomically with sequentially