C ++ 11比较和交换获取/发布语义

Question

Let's assume I have the following code (toy examples):

std::atomic<K *> data;
K *old_value = NULL;
K *new_value = new K();
if (!data.compare_exchange_strong(old_value, new_value, m1, m2)) {
    delete new_value;
}
do_something(old_value);

Or

std::atomic<K *> data;
K *i = data.load(m3);
K *j;
do {
   j = i + 1;
} while (data.compare_exchange_weak(i, j, m4, m5);
do_something(j);

What are valid values of m1 , m2 , m3 , m4 and m5 ? My reading is that all can be std::memory_order_relaxed as the whole code strongly depends on the result of previous operations (assuming do_something just uses the pointer and don't alter the global, shared state). Is my reading correct?

Answer 1

This question only makes sense in a multithreaded scenario with a well-defined shared state. Without knowing what the other thread does, I can only assume that it reads/writes data . With just this single point of synchronization, all-relaxed ordering should do just fine. For any given atomic considered independently of other sync points, operations will still be atomic, and their relative ordering will still be correct.

Now, if the shared state consisted of several variables (that's where the "ordering" comes into play), it would be a totally different story; and you would have to worry about acquire/release/etc. semantics. In this case:

relaxed

• does not guarantee that changes to several variables from one thread will be visible to another thread in the same order;
• does not guarantee that changes to several variables made independently from different threads (eg, thread 1 sets data1 , and thread 2 sets data2 ) will be visible to all the other threads in the same order.

acquire/release (when used on every read/write, respectively; for different patterns of ordering arguments the first item may become more relaxed)

• guarantees that changes to several variables from one thread will be visible to another thread in the same order;
• does not guarantee that changes to several variables made independently from different threads will be visible to all the other threads in the same order.

seq_cst (again, when used on every read/write):

• guarantees that changes to several variables from one thread will be visible to another thread in the same order;
• guarantees that changes to several variables made independently from different threads will be visible to all the other threads in the same order, whatever it may be.