Target Architecture (armv8 compatibility)? about spsc_queue HOT 4 CLOSED

Those asm should only work for X86 platforms, you can think them as a light-weighed version of std::atomic_thread_fence(memory_order_relaxed), becasue x86 has strong memory-order so acquire/release is no different from relaxed.
The main overhead of the general compile-level memory fence(i.e. atomic_thread_fence(memory_order_relaxed)) is that data cached in registers needs to be stored to memory(in case other thread need to read) and then loaded from memory(in case other thread has written it), and compile can't tell what data can be accessed by other threads then it'll be the most conservative.
In using the asms, we explicitly tell the compiler what data can be written or read by the others, so it can do a little optimization(so I call it light-weighted memory fence).
Being said that, from benchmark result I didn't see notable performance difference between asms and std::atomic/memory fence, so I switched to std::atomic as it's more readable and cross-platform.

from spsc_queue.

I've replaced those asm statements with std::atomic to make it cross-platform and performance should be the same. Thanks.

from spsc_queue.

Many thanks for your response. But I was actually not sure if the asm volatile instruction is enough, and was trying to understand if it is sufficient in this case / what the rational behind it is. :)

from spsc_queue.

Thanks for the explanation :-)

from spsc_queue.