Yes, they are different things. But we don't usually specify them separately from C/C++. We just tell the compiler we want a barrier, and it will make sure it doesn't reorder across the barrier, and also make sure the CPU doesn't.mar wrote: Compiler barriers tells the compiler to not reorder instruction it outputs (asm volatile("" ::: "memory") in gcc), which is different from memory barrier instructions that do something similar on CPU (EDIT: wrt. memory access - for nitpicks).
I would assume though that C++11 barriers are hw barriers (or nothing on some architectures), implying compiler barrier automatically.
POSIX synchronization primitives guarantee both kinds of barriers as well. Otherwise there would be no way to write safe multithreading code.
Is there a situation where it's preferable to only have software barriers?
I don't need anything from youWhat do you want from me anyway?If you want to imply that my code is crap, do it straight. I can take it.
. I just wanted to point out that using volatile for sync is undefined behaviour by the standard, in case you didn't know that already. If you do already know, then all is well.I haven't seen your code, so I'll give you benefit of doubt and say it's probably not crap
.