stdatomic | 易学教程

atomic load store with memory order

阅读更多关于 atomic load store with memory order

问题 Thread A runs x.store(1, std::memory_order_release) first, then thread B runs x.load(std::memory_order_acquire) . x in thread B is not guaranteed to read 1 stored by A. If I use memory_order_seq_cst , will it be guaranteed to read 1? 回答1: There is no difference between memory orderings with regards to load/store of one atomic variable. This is because std::memory_order specifies how regular, non-atomic memory accesses are to be ordered around an atomic operation . Read std::memory_order for

What are the correct memory orders to use when inserting a node at the beginning of a lock free singly linked list?

阅读更多关于 What are the correct memory orders to use when inserting a node at the beginning of a lock free singly linked list?

问题 I have a simple linked list. There is no danger of the ABA problem, I'm happy with Blocking category and I don't care if my list is FIFO, LIFO or randomized. At long as the inserting succeeds without making others fails. The code for that looks something like this: class Class { std::atomic<Node*> m_list; ... }; void Class::add(Node* node) { node->next = m_list.load(std::memory_order_acquire); while (!m_list.compare_exchange_weak(node->next, node, std::memory_order_acq_rel, std::memory_order

Memory order consume usage in C11

阅读更多关于 Memory order consume usage in C11

问题 I read about the carries a dependency relation and dependency-ordered before that uses one in its definition 5.1.2.4(p16) : An evaluation A is dependency-ordered before an evaluation B if: — A performs a release operation on an atomic object M , and, in another thread, B performs a consume operation on M and reads a value written by any side effect in the release sequence headed by A , or — for some evaluation X , A is dependency-ordered before X and X carries a dependency to B . So I tried

Is it necessary to use a std::atomic to signal that a thread has finished execution?

阅读更多关于 Is it necessary to use a std::atomic to signal that a thread has finished execution?

问题 I would like to check if a std::thread has finished execution. Searching stackoverflow I found the following question which addresses this issue. The accepted answer proposes having the worker thread set a variable right before exiting and having the main thread check this variable. Here is a minimal working example of such a solution: #include <unistd.h> #include <thread> void work( bool* signal_finished ) { sleep( 5 ); *signal_finished = true; } int main() { bool thread_finished = false;

std::atomic<int> memory_order_relaxed VS volatile sig_atomic_t in a multithreaded program

阅读更多关于 std::atomic memory_order_relaxed VS volatile sig_atomic_t in a multithreaded program

问题 Does volatile sig_atomic_t give any memory order guarantees? E.g. if I need to just load/store an integer is it ok to use? E.g. here: volatile sig_atomic_t x = 0; ... void f() { std::thread t([&] {x = 1;}); while(x != 1) {/*waiting...*/} //done! } is it correct code? Are there conditions it may not work? Note: This is a over-simplifed example, i.e. I am not looking for a better solution for the given piece of code. I just want to understand what kind of behaviour I could expect from volatile

Can atomic loads be merged in the C++ memory model?

阅读更多关于 Can atomic loads be merged in the C++ memory model?

问题 Consider the C++ 11 snippet below. For GCC and clang this compiles to two (sequentially consistent) loads of foo. (Editor's note: compilers do not optimize atomics, see this Q&A for more details, especially http://wg21.link/n4455 standards discussion about the problems this could create which the standard doesn't give programmers tools to work around. This language-lawyer Q&A is about the current standard, not what compilers do.) Does the C++ memory model allow the compiler to merge these two

C++ memory model: do seq_cst loads synchronize with seq_cst stores?

阅读更多关于 C++ memory model: do seq_cst loads synchronize with seq_cst stores?

问题 In the C++ memory model, there is a total order on all loads and stores of all sequentially consistent operations. I'm wondering how this interacts with operations that have other memory orderings that are sequenced before/after sequentially consistent loads. For example, consider two threads: std::atomic<int> a(0); std::atomic<int> b(0); std::atomic<int> c(0); ////////////// // Thread T1 ////////////// // Signal that we've started running. a.store(1, std::memory_order_relaxed); // If T2's

GCC reordering up across load with `memory_order_seq_cst`. Is this allowed?

阅读更多关于 GCC reordering up across load with `memory_order_seq_cst`. Is this allowed?

问题 Using a simplified version of a basic seqlock , gcc reorders a nonatomic load up across an atomic load(memory_order_seq_cst) when compiling the code with -O3 . This reordering isn't observed when compiling with other optimization levels or when compiling with clang ( even on O3 ). This reordering seems to violate a synchronizes-with relationship that should be established and I'm curious to know why gcc reorders this particular load and if this is even allowed by the standard. Consider this

Is there atomic increment with the check preconditions, that the atomic value was less than the specified value?

阅读更多关于 Is there atomic increment with the check preconditions, that the atomic value was less than the specified value?

Is in the new standard C++ atomic increment operation with the check preconditions before the incremented the value, that the atomic value was less than the specified value? Can I do it easier and faster than the following code? int atomic_inc(std::atomic_int& val, int less_than) { int new_val; int old_val = val.load(); do { if (old_val > less_than) return old_val; new_val = old_val + 1; } while (!val.compare_exchange_weak(old_val, new_val)); return new_val; } If somebody don't know how works compare_exchange_weak: compare_exchange_weak reads val, compares with old_val, and if they are not

std::atomic<int> memory_order_relaxed VS volatile sig_atomic_t in a multithreaded program

阅读更多关于 std::atomic memory_order_relaxed VS volatile sig_atomic_t in a multithreaded program

Does volatile sig_atomic_t give any memory order guarantees? E.g. if I need to just load/store an integer is it ok to use? E.g. here: volatile sig_atomic_t x = 0; ... void f() { std::thread t([&] {x = 1;}); while(x != 1) {/*waiting...*/} //done! } is it correct code? Are there conditions it may not work? Note: This is a over-simplifed example, i.e. I am not looking for a better solution for the given piece of code. I just want to understand what kind of behaviour I could expect from volatile sig_atomic_t in a multithreaded program according to the C++ standard. Or, if it is a case, understand