kernel/Documentation/memory-barriers.txt

466  (5) ACQUIRE operations.
469      operations after the ACQUIRE operation will appear to happen after the
470      ACQUIRE operation with respect to the other components of the system.
471      ACQUIRE operations include LOCK operations and both smp_load_acquire()
474      Memory operations that occur before an ACQUIRE operation may appear to
477      An ACQUIRE operation should almost always be paired with a RELEASE
492      The use of ACQUIRE and RELEASE operations generally precludes the need
493      for other sorts of memory barrier.  In addition, a RELEASE+ACQUIRE pair is
495      ACQUIRE on a given variable, all memory accesses preceding any prior
501      This means that ACQUIRE acts as a minimal "acquire" operation and
504 A subset of the atomic operations described in atomic_t.txt have ACQUIRE and
507 store, ACQUIRE semantics apply only to the load and RELEASE semantics apply
927 other types of barriers, albeit without multicopy atomicity.  An acquire
930 with a data dependency barrier, a control dependency, an acquire barrier,
933 with a write barrier, an acquire barrier, a release barrier, or a
1420 chain of release-acquire pairs do not provide this additional ordering,
1461 Furthermore, because of the release-acquire relationship between cpu0()
1467 However, the ordering provided by a release-acquire chain is local
1478 writes in order, CPUs not involved in the release-acquire chain might
1976 In all cases there are variants on "ACQUIRE" operations and "RELEASE" operations
1979  (1) ACQUIRE operation implication:
1981      Memory operations issued after the ACQUIRE will be completed after the
1982      ACQUIRE operation has completed.
1984      Memory operations issued before the ACQUIRE may be completed after
1985      the ACQUIRE operation has completed.
1995  (3) ACQUIRE vs ACQUIRE implication:
1997      All ACQUIRE operations issued before another ACQUIRE operation will be
1998      completed before that ACQUIRE operation.
2000  (4) ACQUIRE vs RELEASE implication:
2002      All ACQUIRE operations issued before a RELEASE operation will be
2005  (5) Failed conditional ACQUIRE implication:
2007      Certain locking variants of the ACQUIRE operation may fail, either due to
2016 An ACQUIRE followed by a RELEASE may not be assumed to be full memory barrier
2017 because it is possible for an access preceding the ACQUIRE to happen after the
2018 ACQUIRE, and an access following the RELEASE to happen before the RELEASE, and
2022 	ACQUIRE M
2028 	ACQUIRE M, STORE *B, STORE *A, RELEASE M
2030 When the ACQUIRE and RELEASE are a lock acquisition and release,
2031 respectively, this same reordering can occur if the lock's ACQUIRE and
2033 another CPU not holding that lock.  In short, a ACQUIRE followed by an
2036 Similarly, the reverse case of a RELEASE followed by an ACQUIRE does
2038 critical sections corresponding to the RELEASE and the ACQUIRE can cross,
2043 	ACQUIRE N
2048 	ACQUIRE N, STORE *B, STORE *A, RELEASE M
2089 	ACQUIRE
2098 	ACQUIRE, {*F,*A}, *E, {*C,*D}, *B, RELEASE
2104 	{*F,*A}, *B,	ACQUIRE, *C, *D,	RELEASE, *E
2105 	*A, *B, *C,	ACQUIRE, *D,		RELEASE, *E, *F
2106 	*A, *B,		ACQUIRE, *C,		RELEASE, *D, *E, *F
2107 	*B,		ACQUIRE, *C, *D,	RELEASE, {*F,*A}, *E
2114 Functions that disable interrupts (ACQUIRE equivalent) and enable interrupts
2298 	ACQUIRE M			ACQUIRE Q
2308 	*E, ACQUIRE M, ACQUIRE Q, *G, *C, *F, *A, *B, RELEASE Q, *D, *H, RELEASE M
2312 	*B, *C or *D preceding ACQUIRE M
2314 	*F, *G or *H preceding ACQUIRE Q