Memory barrier

[Warner Losh]

On Fri, Oct 9, 2015 at 6:15 AM, Leonardo Fogel <leonardofogel at yahoo.com.br>
wrote:

> On Thu, 10/8/15, John-Mark Gurney wrote:
>
> > If this is a PCI device, you need to do a read from the device before
> > it is guaranteed that all the bridges have flushed the writes to the
> > device...  A barrier only guarantees from the processor's perspective
> > that the write "has completed", but not that it will reach the device..
> >
> > If this is a different bus, then the rules are probably different...
>
> Good points. I've ignored them.
> It is a System-on-Chip based on ARM, which has different buses and
> bridges. Device registers are memory-mapped (MMIO).
> The formal definition of memory barriers is quite obscure; in simple
> terms: memory accesses before the barrier are "observed" before memory
> accesses after the barrier. However, the definition of an "observer" is not
> provided. Since the device registers are memory-mapped, I've assumed that a
> write before the barrier would reach the device before a write after the
> barrier. But, on a second thought, the buses and bridges might reorder
> them. I really don't know, but, to be on the safe side, I'll include the
> read.
> Thanks for your attention.
>

Yes, memory barriers are CPU artifacts. They tell you nothing about what
any bridges or other bus technology has done before it reaches the actual
device. If you need write ordering in the actual device, you almost
certainly need to do a read to act as a write barrier.

Warner