Menu
Update 3:
After understanding what "memory order" is, I know the problem is totally not related to compiler.
And yes, because my CPU architecture is Intel x86, no matter what code I write, the memory order effect will never happen.
Update 2:
I check the disassembly code. However, I find no matter how I add code, the x.store always prior to y.store.
The problem should come from compiler (which doesn't reorder these code) instead of CPU (as far as I think).
Update:
After I read comments, it seems like I have to borrow a machine which's CPU is alpha, arm or ppc.
Does anyone know where I can use this kind of machine even this is not for free?
Origin:
I am testing the code below.
atomic<int> x(0);
atomic<int> y(0);
void thr1()
{
x.store(1,memory_order_relaxed);
y.store(1,memory_order_relaxed);
}
void thr2()
{
while(!y.load(memory_order_relaxed))
;
cout<<x.load(memory_order_relaxed)<<endl; //may 0 or 1
}
I know the output may be 0.
However, no matter how much times I tried, I always get 1.
Is this because of my CPU is x86 architecture?
If not, how to fix this problem?
(BTW, I know CppMem. But it cannot use loop.)
351
Loads and Stores For that to be possible, such data must exist in shared memory or cache. Thus, an atomic load loads data from shared memory to either a register or thread-specific memory, depending on the processor architecture. Atomic stores move data into shared memory atomically.
(since C++20) std::memory_order specifies how memory accesses, including regular, non-atomic memory accesses, are to be ordered around an atomic operation.
C++11 Memory Model. A memory model, a.k.a memory consistency model, is a specification of the allowed behavior of multithreaded programs executing with shared memory [1].
The default is std::memory_order_seq_cst which establishes a single total ordering over all atomic operations tagged with this tag: all threads see the same order of such atomic operations and no memory_order_seq_cst atomic operations can be reordered.
What you are experiencing is not a "problem". At least, not as far as the standard is concerned.
When ordering is relaxed, this only means that ordering is no longer guaranteed. This does not mean that implementations must put them into different orders.
A different compiler may show it; then again, it may not. Hell, just changing the optimization might cause it to happen. Then again, maybe not. There is ultimately nothing you can do to guarantee seeing the other order (outside of emulation of some sort or similar tools). Just because you state that something might be possible does not ensure that it will or must happen.
167
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
