On Thu, Jul 03, 2025 at 10:05:59AM +0200, Gabriele Monaco wrote: > Hi all, Hi Gabriele,
> these statements made me curious: I always thought of memory barriers as a way > to order reads and writes to the same address across different CPUs (in other > words, for visibility). > > For instance I'd do something like: > > CPU 1 CPU2 > > write(x) > smp_mb() > <implicit paired barrier> > READ_ONCE(x) > > Now, I get there isn't much we can do if reader and writer are racing, but, as > Steve said, I'm expecting the presence of barriers to make the racing window > smaller. > > Am I misinterpreting the whole thing here? Are those barriers just ordering > reads with reads and writes with writes (hence useful only with multiple > variables)? >From "WHAT ARE MEMORY BARRIERS?" section in https://www.kernel.org/doc/Documentation/memory-barriers.txt "Memory barriers [...] impose a perceived partial ordering over the memory operations on either side of the barrier." and also have a look at "WHAT MAY NOT BE ASSUMED ABOUT MEMORY BARRIERS?" later on: "There is no guarantee that any of the memory accesses specified before a memory barrier will be _complete_ by the completion of a memory barrier instruction" Or data memory barrier explanation from Arm (https://developer.arm.com/documentation/den0042/0100/Memory-Ordering/Memory-barriers) "This instruction ensures that all memory accesses in program order before the barrier are observed in the system before any explicit memory accesses that appear in program order after the barrier. It does not affect the ordering of any other instructions executing on the processor, or of instruction fetches." So yes, smp_rmb() is only useful inbetween reads, and smp_wmb() is only userful inbetween writes. Best regards, Nam
