Thanks for your reply. This subject is still new to me.
My understanding of that syntax is that it is a compiler memory barrier, not a CPU memory barrier because the asm block is empty (no sfence or mfence).
My understanding of that syntax is that it is a compiler memory barrier, not a CPU memory barrier because the asm block is empty (no sfence or mfence).
> My understanding of that syntax is that it is a compiler memory barrier, not a CPU memory barrier because the asm block is empty (no sfence or mfence).
In C11, you can write compiler-only fences with atomic_signal_fence:
https://en.cppreference.com/w/c/atomic/atomic_signal_fence
(In practice, though, I think it is rare that you actually want a compiler-only fence. Instead, correct use of acquire/release operations prevents reorderings.)
I've been using a compiler fence to force reloads from memory to prevent -O3 from optimising away my variables/structs changing by other threads and keeping data in registers rather than reloading from memory each time. I saw the volatile recommended against from the Linux kernel programmers.
such as my thread->running == 1 in my event loops for my threads.
https://www.kernel.org/doc/html/latest/process/volatile-cons...
I would highly recommend using the language standard atomic primitives instead.