Documentation/memory-barriers.txt: How can READ_ONCE() and WRITE_ONCE() provide cache coherence?

From: Sergey Fedorov
Date: Fri Feb 26 2016 - 16:14:30 EST


I just can't understand how this kind of compiler barrier macros may provide any form of cache coherence. Sure, such kind of compiler barrier is necessary to "reliably" access a variable from multiple CPUs. But why it is stated that these macros *provide* cache coherence?

From Documentation/memory-barriers.txt:
The READ_ONCE() and WRITE_ONCE() functions can prevent any number of
optimizations that, while perfectly safe in single-threaded code, can
be fatal in concurrent code. Here are some examples of these sorts
of optimizations:

(*) The compiler is within its rights to reorder loads and stores
to the same variable, and in some cases, the CPU is within its
rights to reorder loads to the same variable. This means that
the following code:

a[0] = x;
a[1] = x;

Might result in an older value of x stored in a[1] than in a[0].
Prevent both the compiler and the CPU from doing this as follows:

a[0] = READ_ONCE(x);
a[1] = READ_ONCE(x);

In short, READ_ONCE() and WRITE_ONCE() provide cache coherence for
accesses from multiple CPUs to a single variable.