stdatomic

reordering atomic operations in C++

醉酒当歌 提交于 2020-01-10 02:53:27
问题 Suppose I have 2 threads: int value = 0; std::atomic<bool> ready = false; thread 1: value = 1 ready = true; thread 2: while (!ready); std::cout << value; Is this program able to output 0? I read about the C++ memory model - specifically, sequential consistency, which I believe is the default, and it wasn't particularly clear. Is the compiler only required to put atomic operations in the correct order relative to each other, or is it required to put atomic operations in the right order

The same instances of the same class but different behaviour. Probable UB

拜拜、爱过 提交于 2020-01-05 04:22:07
问题 #include <iostream> #include <atomic> #include <memory> template<typename T> class LockFreeQueue { public: struct CountedNode; private: std::atomic<CountedNode> head; public: struct Node{ explicit Node(const T& d) : next(CountedNode()), data(std::make_shared<T>(d)), node_counter(0) { } std::atomic<CountedNode> next; std::shared_ptr<T> data; std::atomic<unsigned> node_counter; }; struct CountedNode { CountedNode() noexcept : node(nullptr), counter(0) {} explicit CountedNode( const T& data)

Implementing 64 bit atomic counter with 32 bit atomics

天涯浪子 提交于 2019-12-30 13:10:48
问题 I would like to cobble together a uint64 atomic counter from atomic uint32s. The counter has a single writer and multiple readers. The writer is a signal handler so it must not block. My idea is to use a generation count with the low bit as a read lock. The reader retries until the generation count is stable across the read, and the low bit is unset. Is the following code correct in design and use of memory ordering? Is there a better way? using namespace std; class counter { atomic<uint32_t>

C++20 std::atomic<float>- std::atomic<double>.specializations

早过忘川 提交于 2019-12-29 09:33:07
问题 C++20 includes specializations for atomic<float> and atomic<double> . Can anyone here explain for what practical purpose this should be good for? The only purpose I can imagine is when I have a thread that changes an atomic double or float asynchronously at random points and other threads read this values asynchronously (but a volatile double or float should in fact do the same on most platforms). But the need for this should be extremely rare. I think this rare case couldn't justify an

What formally guarantees that non-atomic variables can't see out-of-thin-air values and create a data race like atomic relaxed theoretically can?

▼魔方 西西 提交于 2019-12-29 01:17:33
问题 This is a question about the formal guarantees of the C++ standard. The standard points out that the rules for std::memory_order_relaxed atomic variables allow "out of thin air" / "out of the blue" values to appear. But for non-atomic variables, can this example have UB? Is r1 == r2 == 42 possible in the C++ abstract machine? Neither variable == 42 initially so you'd expect neither if body should execute, meaning no writes to the shared variables. // Global state int x = 0, y = 0; // Thread 1

Approach of using an std::atomic compared to std::condition_variable wrt pausing & resuming an std::thread in C++

☆樱花仙子☆ 提交于 2019-12-23 09:25:30
问题 This is a separate question but related to the previous question I asked here I am using an std::thread in my C++ code to constantly poll for some data & add it to a buffer. I use a C++ lambda to start the thread like this: StartMyThread() { thread_running = true; the_thread = std::thread { [this] { while(thread_running) { GetData(); } }}; } thread_running is an atomic<bool> declared in class header. Here is my GetData function: GetData() { //Some heavy logic } Next I also have a StopMyThread

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

喜你入骨 提交于 2019-12-22 09:49:17
问题 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

Is it possible to have a release-sequence from a release store operation to a store in a different thread?

时间秒杀一切 提交于 2019-12-22 05:53:22
问题 I'm aware that a synchronizes-with relationship will occur between a release store operation in thread 2 and a acquire load operation in thread 1 even if that load operation isn't directly reading the value stored by thread 2, provided that there is a "release sequence" between the release store operation and the store that is actually being read as long as: The store that is actually being read is in the same thread as the release store operation. In modification-order there is no store in

Can std::atomic be safely used with OpenMP

◇◆丶佛笑我妖孽 提交于 2019-12-22 04:01:21
问题 I'm currently trying to learn ow to use OpenMP and I have a question. Is it safe to do something like that : std::atomic<double> result; #pragma omp parallel for for(...) { result+= //some stuff; } Or shall I use : double result; #pragma omp parallel for for(...) { double tmp=0; //some stuff; #pragma omp atomic result+=tmp; } Thanks ! Edit : I know the most simple way to handle that is using an array, but Im asking because I'm curious 回答1: Officially, no. In practice, probably. Page Section 1

error C2280: attempting to reference a deleted function (atomic<int>)

别等时光非礼了梦想. 提交于 2019-12-21 04:46:11
问题 I have a class A with a member variable _atomicVar of type std::atomic<int> . #include <atomic> class A { public: A(); ~A(); private: std::atomic<int> _atomicVar; }; If I build the project I get the following error: error C2280: 'std::atomic<int>::atomic(const std::atomic<int> &)' : attempting to reference a deleted function I'm mainly a C# developer so I don't know every detail of C++ (yet). I don't know where I use the copy c'tor of atomic<int> . I also tried to initialize _atomicVar : std: