Lines Matching refs: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.
239 emits a memory-barrier instruction, so that a DEC Alpha CPU will
365 ordering over the memory operations on either side of the barrier.
382 A write memory barrier gives a guarantee that all the STORE operations
383 specified before the barrier will appear to happen before all the STORE
384 operations specified after the barrier with respect to the other
387 A write barrier is a partial ordering on stores only; it is not required
391 memory system as time progresses. All stores _before_ a write barrier
392 will occur _before_ all the stores after the write barrier.
395 address-dependency barriers; see the "SMP barrier pairing" subsection.
400 An address-dependency barrier is a weaker form of read barrier. In the
403 the second load will be directed), an address-dependency barrier would
407 An address-dependency barrier is a partial ordering on interdependent
413 considered can then perceive. An address-dependency barrier issued by
416 by the time the barrier completes, the effects of all the stores prior to
418 the address-dependency barrier.
420 See the "Examples of memory barrier sequences" subsection for diagrams
427 a full read barrier or better is required. See the "Control dependencies"
431 write barriers; see the "SMP barrier pairing" subsection.
440 A read barrier is an address-dependency barrier plus a guarantee that all
441 the LOAD operations specified before the barrier will appear to happen
442 before all the LOAD operations specified after the barrier with respect to
445 A read barrier is a partial ordering on loads only; it is not required to
452 see the "SMP barrier pairing" subsection.
457 A general memory barrier gives a guarantee that all the LOAD and STORE
458 operations specified before the barrier will appear to happen before all
459 the LOAD and STORE operations specified after the barrier with respect to
462 A general memory barrier is a partial ordering over both loads and stores.
472 This acts as a one-way permeable barrier. It guarantees that all memory
487 This also acts as a one-way permeable barrier. It guarantees that all
497 for other sorts of memory barrier. In addition, a RELEASE+ACQUIRE pair is
498 -not- guaranteed to act as a full memory barrier. However, after an
509 RELEASE variants in addition to fully-ordered and relaxed (no barrier
531 memory barrier will be _complete_ by the completion of a memory barrier
532 instruction; the barrier can be considered to draw a line in that CPU's
535 (*) There is no guarantee that issuing a memory barrier on one CPU will have
542 barrier, unless the first CPU _also_ uses a matching memory barrier (see
547 mechanisms should propagate the indirect effects of a memory barrier
579 <write barrier>
585 doesn't imply an address-dependency barrier.
602 To deal with this, READ_ONCE() provides an implicit address-dependency barrier
609 <write barrier>
612 <implicit address-dependency barrier>
629 An address-dependency barrier is not required to order dependent writes
641 <write barrier>
646 Therefore, no address-dependency barrier is required to order the read into
648 even without an implicit address-dependency barrier of modern READ_ONCE():
664 The address-dependency barrier is very important to the RCU system,
680 A load-load control dependency requires a full read memory barrier, not
681 simply an (implicit) address-dependency barrier to make it work correctly.
685 <implicit address-dependency barrier>
699 <read barrier>
733 barrier();
737 barrier();
746 barrier();
810 tempting to add a barrier(), but this does not help. The conditional
811 is gone, and the barrier won't bring it back. Therefore, if you are
900 to use barrier() at beginning of each leg of the "if" statement
903 barrier() law.
935 When dealing with CPU-CPU interactions, certain types of memory barrier should
940 barrier pairs with a release barrier, but both may also pair with other
941 barriers, including of course general barriers. A write barrier pairs
942 with an address-dependency barrier, a control dependency, an acquire barrier,
943 a release barrier, a read barrier, or a general barrier. Similarly a
944 read barrier, control dependency, or an address-dependency barrier pairs
945 with a write barrier, an acquire barrier, a release barrier, or a
946 general barrier:
951 <write barrier>
953 <read barrier>
961 <write barrier>
963 <implicit address-dependency barrier>
971 <general barrier>
979 Basically, the read barrier always has to be there, even though it can be of
982 [!] Note that the stores before the write barrier would normally be expected to
983 match the loads after the read barrier or the address-dependency barrier, and
990 <write barrier> \ <read barrier>
1006 <write barrier>
1023 | | wwwwwwwwwwwwwwww } <--- At this point the write barrier
1025 | | : | E=5 | } barrier to be committed before
1044 <write barrier>
1050 effectively random order, despite the write barrier issued by CPU 1:
1082 If, however, an address-dependency barrier were to be placed between the load
1090 <write barrier>
1093 <address-dependency barrier>
1123 And thirdly, a read barrier acts as a partial order on loads. Consider the
1130 <write barrier>
1136 some effectively random order, despite the write barrier issued by CPU 1:
1159 If, however, a read barrier were to be placed between the load of B and the
1166 <write barrier>
1169 <read barrier>
1189 barrier causes all effects \ +-------+ | |
1196 contained a load of A either side of the read barrier:
1202 <write barrier>
1206 <read barrier>
1229 barrier causes all effects \ +-------+ | |
1236 before the read barrier completes anyway:
1307 Placing a read barrier or an address-dependency barrier just before the second
1315 <read barrier>
1319 dependent on the type of barrier used. If there was no change made to the
1382 <general barrier> <read barrier>
1401 The use of a general memory barrier in the example above compensates
1408 that CPU 2's general barrier is removed from the above example, leaving
1415 <data dependency> <read barrier>
1492 the weak memory-barrier instructions used to implement smp_load_acquire()
1520 (*) Compiler barrier.
1528 The Linux kernel has an explicit compiler barrier function that prevents the
1531 barrier();
1533 This is a general barrier -- there are no read-read or write-write
1534 variants of barrier(). However, READ_ONCE() and WRITE_ONCE() can be
1535 thought of as weak forms of barrier() that affect only the specific
1538 The barrier() function has the following effects:
1541 barrier() to precede any accesses preceding the barrier().
1730 barrier(), or similar primitives.
1732 This effect could also be achieved using barrier(), but READ_ONCE()
1735 indicated memory locations, while with barrier() the compiler must
1842 barrier. Address dependencies do not impose any additional compiler ordering.
1871 There are some more advanced barrier functions:
1876 barrier after it. It isn't guaranteed to insert anything more than a
1877 compiler barrier in a UP compilation.
1884 barriers, but where the code needs a memory barrier. Examples for atomic
1885 RMW functions that do not imply a memory barrier are e.g. add,
1888 barrier may be required is when atomic ops are used for reference
1892 memory barrier (such as set_bit and clear_bit).
2031 locks do not imply any sort of barrier.
2037 An ACQUIRE followed by a RELEASE may not be assumed to be full memory barrier
2055 RELEASE may -not- be assumed to be a full memory barrier.
2058 not imply a full memory barrier. Therefore, the CPU's execution of the
2093 a memory barrier, which will force the earlier unlock operation
2103 See also the section on "Inter-CPU acquiring barrier effects".
2160 A general memory barrier is interpolated automatically by set_current_state()
2168 <general barrier>
2176 which therefore also imply a general memory barrier after setting the state.
2178 interpolate the memory barrier in the right place:
2200 A general memory barrier is executed by wake_up() if it wakes something up.
2201 If it doesn't wake anything up then a memory barrier may or may not be
2202 executed; you must not rely on it. The barrier occurs before the task state
2211 <general barrier> <general barrier>
2217 To repeat, a general memory barrier is guaranteed to be executed by wake_up()
2231 wake_up_process() always executes a general memory barrier. The barrier again
2305 On SMP systems locking primitives give a more substantial form of barrier: one
2437 The way to deal with this is to insert a general SMP memory barrier:
2446 In this case, the barrier makes a guarantee that all memory accesses before the
2447 barrier will appear to happen before all the memory accesses after the barrier
2449 the memory accesses before the barrier will be complete by the time the barrier
2453 compiler barrier, thus making sure the compiler emits the instructions in the
2778 A memory barrier isn't sufficient in such a case, but rather the cache must be
2840 barrier. For instance with the following code:
2884 since, without either a write barrier or an WRITE_ONCE(), it can be
2890 may, without a memory barrier or an READ_ONCE() and WRITE_ONCE(), be
2905 the address-dependency barrier really becomes necessary as this synchronises