Lines Matching refs:RELEASE
439 An ACQUIRE operation should almost always be paired with a RELEASE
443 (6) RELEASE operations.
446 memory operations before the RELEASE operation will appear to happen
447 before the RELEASE operation with respect to the other components of the
448 system. RELEASE operations include UNLOCK operations and
451 Memory operations that occur after a RELEASE operation may appear to
454 The use of ACQUIRE and RELEASE operations generally precludes the need
456 the subsection "MMIO write barrier"). In addition, a RELEASE+ACQUIRE
459 RELEASE on that same variable are guaranteed to be visible. In other
465 RELEASE acts as a minimal "release" operation.
1777 In all cases there are variants on "ACQUIRE" operations and "RELEASE" operations
1792 (2) RELEASE operation implication:
1794 Memory operations issued before the RELEASE will be completed before the
1795 RELEASE operation has completed.
1797 Memory operations issued after the RELEASE may be completed before the
1798 RELEASE operation has completed.
1805 (4) ACQUIRE vs RELEASE implication:
1807 All ACQUIRE operations issued before a RELEASE operation will be
1808 completed before the RELEASE operation.
1821 An ACQUIRE followed by a RELEASE may not be assumed to be full memory barrier
1823 ACQUIRE, and an access following the RELEASE to happen before the RELEASE, and
1828 RELEASE M
1833 ACQUIRE M, STORE *B, STORE *A, RELEASE M
1835 When the ACQUIRE and RELEASE are a lock acquisition and release,
1837 RELEASE are to the same lock variable, but only from the perspective of
1839 RELEASE may -not- be assumed to be a full memory barrier.
1841 Similarly, the reverse case of a RELEASE followed by an ACQUIRE does not
1842 imply a full memory barrier. If it is necessary for a RELEASE-ACQUIRE
1845 if either (a) the RELEASE and the ACQUIRE are executed by the same
1846 CPU or task, or (b) the RELEASE and ACQUIRE act on the same variable.
1849 sections corresponding to the RELEASE and the ACQUIRE can cross, so that:
1852 RELEASE M
1858 ACQUIRE N, STORE *B, STORE *A, RELEASE M
1862 the RELEASE would simply complete, thereby avoiding the deadlock.
1892 RELEASE M
1899 STORE *A, RELEASE, ACQUIRE, smp_mb__after_unlock_lock(), STORE *B
1900 STORE *A, ACQUIRE, RELEASE, smp_mb__after_unlock_lock(), STORE *B
1901 ACQUIRE, STORE *A, RELEASE, smp_mb__after_unlock_lock(), STORE *B
1903 If the RELEASE and ACQUIRE were instead both operating on the same lock
1925 RELEASE
1931 ACQUIRE, {*F,*A}, *E, {*C,*D}, *B, RELEASE
1937 {*F,*A}, *B, ACQUIRE, *C, *D, RELEASE, *E
1938 *A, *B, *C, ACQUIRE, *D, RELEASE, *E, *F
1939 *A, *B, ACQUIRE, *C, RELEASE, *D, *E, *F
1940 *B, ACQUIRE, *C, *D, RELEASE, {*F,*A}, *E
1948 (RELEASE equivalent) will act as compiler barriers only. So if memory or I/O
2123 RELEASE M RELEASE Q
2130 *E, ACQUIRE M, ACQUIRE Q, *G, *C, *F, *A, *B, RELEASE Q, *D, *H, RELEASE M
2135 *A, *B or *C following RELEASE M
2137 *E, *F or *G following RELEASE Q
2148 RELEASE M [1]
2154 RELEASE M [2]
2159 *E, ACQUIRE M [1], *C, *B, *A, RELEASE M [1],
2160 ACQUIRE M [2], *H, *F, *G, RELEASE M [2], *D
2165 *A, *B or *C following RELEASE M [1]
2167 *A, *B, *C, *E, *F or *G following RELEASE M [2]
2306 RELEASE task
2348 RELEASE task
2394 These are used for such things as implementing ACQUIRE-class and RELEASE-class
2400 barriers, but might be used for implementing such things as RELEASE-class
2442 These implement ACQUIRE-class and RELEASE-class operations. These should be used in