perfbook | mirror of git :

You're correct, memory barriers can't create atomicity. They only order this core's own accesses to its L1d cache (e.g. drain the store buffer before later stores or loads = full barrier, or wait for earlier loads to read cache before any later loads and stores can execute = light-weight barrier). They don't bundle together multiple instructions into an atomic RMW transaction.

To create atomicity wrt. anything another core can do, you need this core to keep the cache line in MESI Exclusive or Modified state from the load to the store (Can num++ be atomic for 'int num'?). Barriers don't do that, you need special asm instructions like x86 lock add dword [mem], 1 or on many RISC-like machines, an LL/SC retry loop that aborts the store if the cache line hasn't stayed exclusive to this core since the load-linked.

Memory barriers are important for C++ std::atomic because that also implies ordering (acquire, release, or seq_cst), unless you use memory_order_relaxed in which case compilers will never use barrier instructions.