Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()

  smp_mb__{before,after}_atomic()

only apply to the RMW ops and can be used to augment/upgrade the ordering

inherent to the used atomic op. These barriers provide a full smp_mb().

only apply to the RMW atomic ops and can be used to augment/upgrade the

ordering inherent to the op. These barriers act almost like a full smp_mb():

smp_mb__before_atomic() orders all earlier accesses against the RMW op

itself and all accesses following it, and smp_mb__after_atomic() orders all

later accesses against the RMW op and all accesses preceding it. However,

accesses between the smp_mb__{before,after}_atomic() and the RMW op are not

ordered, so it is advisable to place the barrier right next to the RMW atomic

op whenever possible.

These helper barriers exist because architectures have varying implicit

ordering on their SMP atomic primitives. For example our TSO architectures

  atomic_dec(&X);

is a 'typical' RELEASE pattern, the barrier is strictly stronger than

a RELEASE. Similarly for something like:

a RELEASE because it orders preceding instructions against both the read

and write parts of the atomic_dec(), and against all following instructions

as well. Similarly, something like:

  atomic_inc(&X);

  smp_mb__after_atomic();

This should not happen; but a hypothetical atomic_inc_acquire() --

(void)atomic_fetch_inc_acquire() for instance -- would allow the outcome,

since then:

because it would not order the W part of the RMW against the following

WRITE_ONCE.  Thus:

  P1			P2