Lines Matching full:barrier
29 particular barrier, and
34 for any particular barrier, but if the architecture provides less than
37 Note also that it is possible that a barrier may be a no-op for an
38 architecture because the way that arch works renders an explicit barrier
53 - Varieties of memory barrier.
57 - SMP barrier pairing.
58 - Examples of memory barrier sequences.
64 - Compiler barrier.
74 (*) Inter-CPU acquiring barrier effects.
85 (*) Kernel I/O barrier effects.
238 emits a memory-barrier instruction, so that a DEC Alpha CPU will
272 the COMPILER BARRIER section.
364 ordering over the memory operations on either side of the barrier.
374 VARIETIES OF MEMORY BARRIER
381 A write memory barrier gives a guarantee that all the STORE operations
382 specified before the barrier will appear to happen before all the STORE
383 operations specified after the barrier with respect to the other
386 A write barrier is a partial ordering on stores only; it is not required
390 memory system as time progresses. All stores _before_ a write barrier
391 will occur _before_ all the stores after the write barrier.
394 address-dependency barriers; see the "SMP barrier pairing" subsection.
404 An address-dependency barrier is a weaker form of read barrier. In the
407 the second load will be directed), an address-dependency barrier would
411 An address-dependency barrier is a partial ordering on interdependent
417 considered can then perceive. An address-dependency barrier issued by
420 by the time the barrier completes, the effects of all the stores prior to
422 the address-dependency barrier.
424 See the "Examples of memory barrier sequences" subsection for diagrams
431 a full read barrier or better is required. See the "Control dependencies"
435 write barriers; see the "SMP barrier pairing" subsection.
444 A read barrier is an address-dependency barrier plus a guarantee that all
445 the LOAD operations specified before the barrier will appear to happen
446 before all the LOAD operations specified after the barrier with respect to
449 A read barrier is a partial ordering on loads only; it is not required to
456 see the "SMP barrier pairing" subsection.
461 A general memory barrier gives a guarantee that all the LOAD and STORE
462 operations specified before the barrier will appear to happen before all
463 the LOAD and STORE operations specified after the barrier with respect to
466 A general memory barrier is a partial ordering over both loads and stores.
476 This acts as a one-way permeable barrier. It guarantees that all memory
491 This also acts as a one-way permeable barrier. It guarantees that all
501 for other sorts of memory barrier. In addition, a RELEASE+ACQUIRE pair is
502 -not- guaranteed to act as a full memory barrier. However, after an
513 RELEASE variants in addition to fully-ordered and relaxed (no barrier
535 memory barrier will be _complete_ by the completion of a memory barrier
536 instruction; the barrier can be considered to draw a line in that CPU's
539 (*) There is no guarantee that issuing a memory barrier on one CPU will have
546 barrier, unless the first CPU _also_ uses a matching memory barrier (see
547 the subsection on "SMP Barrier Pairing").
551 mechanisms should propagate the indirect effects of a memory barrier
588 <write barrier>
594 doesn't imply an address-dependency barrier.
611 To deal with this, READ_ONCE() provides an implicit address-dependency barrier
618 <write barrier>
621 <implicit address-dependency barrier>
638 An address-dependency barrier is not required to order dependent writes
650 <write barrier>
655 Therefore, no address-dependency barrier is required to order the read into
657 even without an implicit address-dependency barrier of modern READ_ONCE():
673 The address-dependency barrier is very important to the RCU system,
687 A load-load control dependency requires a full read memory barrier, not
688 simply an (implicit) address-dependency barrier to make it work correctly.
692 <implicit address-dependency barrier>
706 <read barrier>
740 barrier();
744 barrier();
753 barrier();
817 tempting to add a barrier(), but this does not help. The conditional
818 is gone, and the barrier won't bring it back. Therefore, if you are
907 to use barrier() at beginning of each leg of the "if" statement
910 barrier() law.
922 Please see the COMPILER BARRIER section for more information.
939 SMP BARRIER PAIRING
942 When dealing with CPU-CPU interactions, certain types of memory barrier should
947 barrier pairs with a release barrier, but both may also pair with other
948 barriers, including of course general barriers. A write barrier pairs
949 with an address-dependency barrier, a control dependency, an acquire barrier,
950 a release barrier, a read barrier, or a general barrier. Similarly a
951 read barrier, control dependency, or an address-dependency barrier pairs
952 with a write barrier, an acquire barrier, a release barrier, or a
953 general barrier:
958 <write barrier>
960 <read barrier>
968 <write barrier>
970 <implicit address-dependency barrier>
978 <general barrier>
986 Basically, the read barrier always has to be there, even though it can be of
989 [!] Note that the stores before the write barrier would normally be expected to
990 match the loads after the read barrier or the address-dependency barrier, and
997 <write barrier> \ <read barrier>
1002 EXAMPLES OF MEMORY BARRIER SEQUENCES
1013 <write barrier>
1030 | | wwwwwwwwwwwwwwww } <--- At this point the write barrier
1032 | | : | E=5 | } barrier to be committed before
1051 <write barrier>
1057 effectively random order, despite the write barrier issued by CPU 1:
1089 If, however, an address-dependency barrier were to be placed between the load
1097 <write barrier>
1100 <address-dependency barrier>
1130 And thirdly, a read barrier acts as a partial order on loads. Consider the
1137 <write barrier>
1143 some effectively random order, despite the write barrier issued by CPU 1:
1166 If, however, a read barrier were to be placed between the load of B and the
1173 <write barrier>
1176 <read barrier>
1196 barrier causes all effects \ +-------+ | |
1203 contained a load of A either side of the read barrier:
1209 <write barrier>
1213 <read barrier>
1236 barrier causes all effects \ +-------+ | |
1243 before the read barrier completes anyway:
1314 Placing a read barrier or an address-dependency barrier just before the second
1322 <read barrier>
1326 dependent on the type of barrier used. If there was no change made to the
1389 <general barrier> <read barrier>
1408 The use of a general memory barrier in the example above compensates
1415 that CPU 2's general barrier is removed from the above example, leaving
1422 <data dependency> <read barrier>
1499 the weak memory-barrier instructions used to implement smp_load_acquire()
1527 (*) Compiler barrier.
1532 COMPILER BARRIER
1535 The Linux kernel has an explicit compiler barrier function that prevents the
1538 barrier();
1540 This is a general barrier -- there are no read-read or write-write
1541 variants of barrier(). However, READ_ONCE() and WRITE_ONCE() can be
1542 thought of as weak forms of barrier() that affect only the specific
1545 The barrier() function has the following effects:
1548 barrier() to precede any accesses preceding the barrier().
1737 barrier(), or similar primitives.
1739 This effect could also be achieved using barrier(), but READ_ONCE()
1742 indicated memory locations, while with barrier() the compiler must
1849 barrier. Address dependencies do not impose any additional compiler ordering.
1878 There are some more advanced barrier functions:
1883 barrier after it. It isn't guaranteed to insert anything more than a
1884 compiler barrier in a UP compilation.
1891 barriers, but where the code needs a memory barrier. Examples for atomic
1892 RMW functions that do not imply a memory barrier are e.g. add,
1895 barrier may be required is when atomic ops are used for reference
1899 memory barrier (such as set_bit and clear_bit).
1955 accesses to MMIO regions. See the later "KERNEL I/O BARRIER EFFECTS"
2038 locks do not imply any sort of barrier.
2044 An ACQUIRE followed by a RELEASE may not be assumed to be full memory barrier
2062 RELEASE may -not- be assumed to be a full memory barrier.
2065 not imply a full memory barrier. Therefore, the CPU's execution of the
2100 a memory barrier, which will force the earlier unlock operation
2110 See also the section on "Inter-CPU acquiring barrier effects".
2167 A general memory barrier is interpolated automatically by set_current_state()
2175 <general barrier>
2183 which therefore also imply a general memory barrier after setting the state.
2185 interpolate the memory barrier in the right place:
2207 A general memory barrier is executed by wake_up() if it wakes something up.
2208 If it doesn't wake anything up then a memory barrier may or may not be
2209 executed; you must not rely on it. The barrier occurs before the task state
2218 <general barrier> <general barrier>
2224 To repeat, a general memory barrier is guaranteed to be executed by wake_up()
2238 wake_up_process() always executes a general memory barrier. The barrier again
2309 INTER-CPU ACQUIRING BARRIER EFFECTS
2312 On SMP systems locking primitives give a more substantial form of barrier: one
2444 The way to deal with this is to insert a general SMP memory barrier:
2453 In this case, the barrier makes a guarantee that all memory accesses before the
2454 barrier will appear to happen before all the memory accesses after the barrier
2456 the memory accesses before the barrier will be complete by the time the barrier
2460 compiler barrier, thus making sure the compiler emits the instructions in the
2548 KERNEL I/O BARRIER EFFECTS
2785 A memory barrier isn't sufficient in such a case, but rather the cache must be
2847 barrier. For instance with the following code:
2891 since, without either a write barrier or an WRITE_ONCE(), it can be
2897 may, without a memory barrier or an READ_ONCE() and WRITE_ONCE(), be
2912 the address-dependency barrier really becomes necessary as this synchronises