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 dependency barriers; see the "SMP barrier pairing" subsection.
400 A data dependency barrier is a weaker form of read barrier. In the case
403 load will be directed), a data dependency barrier would be required to
407 A data dependency barrier is a partial ordering on interdependent loads
413 considered can then perceive. A data dependency barrier issued by the CPU
416 time the barrier completes, the effects of all the stores prior to that
418 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.
436 A read barrier is a data dependency barrier plus a guarantee that all the
437 LOAD operations specified before the barrier will appear to happen before
438 all the LOAD operations specified after the barrier with respect to the
441 A read barrier is a partial ordering on loads only; it is not required to
448 see the "SMP barrier pairing" subsection.
453 A general memory barrier gives a guarantee that all the LOAD and STORE
454 operations specified before the barrier will appear to happen before all
455 the LOAD and STORE operations specified after the barrier with respect to
458 A general memory barrier is a partial ordering over both loads and stores.
468 This acts as a one-way permeable barrier. It guarantees that all memory
483 This also acts as a one-way permeable barrier. It guarantees that all
493 for other sorts of memory barrier. In addition, a RELEASE+ACQUIRE pair is
494 -not- guaranteed to act as a full memory barrier. However, after an
505 RELEASE variants in addition to fully-ordered and relaxed (no barrier
527 memory barrier will be _complete_ by the completion of a memory barrier
528 instruction; the barrier can be considered to draw a line in that CPU's
531 (*) There is no guarantee that issuing a memory barrier on one CPU will have
538 barrier, unless the first CPU _also_ uses a matching memory barrier (see
543 mechanisms should propagate the indirect effects of a memory barrier
571 <write barrier>
591 To deal with this, a data dependency barrier or better must be inserted
598 <write barrier>
601 <data dependency barrier>
618 A data-dependency barrier is not required to order dependent writes
630 <write barrier>
635 Therefore, no data-dependency barrier is required to order the read into
637 even without a data-dependency barrier:
653 The data dependency barrier is very important to the RCU system,
669 A load-load control dependency requires a full read memory barrier, not
670 simply a data dependency barrier to make it work correctly. Consider the
675 <data dependency barrier> /* BUG: No data dependency!!! */
687 <read barrier>
721 barrier();
725 barrier();
734 barrier();
798 tempting to add a barrier(), but this does not help. The conditional
799 is gone, and the barrier won't bring it back. Therefore, if you are
888 to use barrier() at beginning of each leg of the "if" statement
891 barrier() law.
923 When dealing with CPU-CPU interactions, certain types of memory barrier should
928 barrier pairs with a release barrier, but both may also pair with other
929 barriers, including of course general barriers. A write barrier pairs
930 with a data dependency barrier, a control dependency, an acquire barrier,
931 a release barrier, a read barrier, or a general barrier. Similarly a
932 read barrier, control dependency, or a data dependency barrier pairs
933 with a write barrier, an acquire barrier, a release barrier, or a
934 general barrier:
939 <write barrier>
941 <read barrier>
949 <write barrier>
951 <data dependency barrier>
959 <general barrier>
967 Basically, the read barrier always has to be there, even though it can be of
970 [!] Note that the stores before the write barrier would normally be expected to
971 match the loads after the read barrier or the data dependency barrier, and vice
978 <write barrier> \ <read barrier>
994 <write barrier>
1011 | | wwwwwwwwwwwwwwww } <--- At this point the write barrier
1013 | | : | E=5 | } barrier to be committed before
1032 <write barrier>
1038 effectively random order, despite the write barrier issued by CPU 1:
1070 If, however, a data dependency barrier were to be placed between the load of C
1078 <write barrier>
1081 <data dependency barrier>
1111 And thirdly, a read barrier acts as a partial order on loads. Consider the
1118 <write barrier>
1124 some effectively random order, despite the write barrier issued by CPU 1:
1147 If, however, a read barrier were to be placed between the load of B and the
1154 <write barrier>
1157 <read barrier>
1177 barrier causes all effects \ +-------+ | |
1184 contained a load of A either side of the read barrier:
1190 <write barrier>
1194 <read barrier>
1217 barrier causes all effects \ +-------+ | |
1224 before the read barrier completes anyway:
1295 Placing a read barrier or a data dependency barrier just before the second
1303 <read barrier>
1307 dependent on the type of barrier used. If there was no change made to the
1370 <general barrier> <read barrier>
1389 The use of a general memory barrier in the example above compensates
1396 that CPU 2's general barrier is removed from the above example, leaving
1403 <data dependency> <read barrier>
1480 the weak memory-barrier instructions used to implement smp_load_acquire()
1508 (*) Compiler barrier.
1516 The Linux kernel has an explicit compiler barrier function that prevents the
1519 barrier();
1521 This is a general barrier -- there are no read-read or write-write
1522 variants of barrier(). However, READ_ONCE() and WRITE_ONCE() can be
1523 thought of as weak forms of barrier() that affect only the specific
1526 The barrier() function has the following effects:
1529 barrier() to precede any accesses preceding the barrier().
1718 barrier(), or similar primitives.
1720 This effect could also be achieved using barrier(), but READ_ONCE()
1723 indicated memory locations, while with barrier() the compiler must
1830 barrier. Data dependencies do not impose any additional compiler ordering.
1859 There are some more advanced barrier functions:
1864 barrier after it. It isn't guaranteed to insert anything more than a
1865 compiler barrier in a UP compilation.
1872 barriers, but where the code needs a memory barrier. Examples for atomic
1873 RMW functions that do not imply are memory barrier are e.g. add,
1876 barrier may be required is when atomic ops are used for reference
1880 memory barrier (such as set_bit and clear_bit).
1934 See the subsection "Kernel I/O barrier effects" for more information on
2010 locks do not imply any sort of barrier.
2016 An ACQUIRE followed by a RELEASE may not be assumed to be full memory barrier
2034 RELEASE may -not- be assumed to be a full memory barrier.
2037 not imply a full memory barrier. Therefore, the CPU's execution of the
2072 a memory barrier, which will force the earlier unlock operation
2082 See also the section on "Inter-CPU acquiring barrier effects".
2139 A general memory barrier is interpolated automatically by set_current_state()
2147 <general barrier>
2155 which therefore also imply a general memory barrier after setting the state.
2157 interpolate the memory barrier in the right place:
2179 A general memory barrier is executed by wake_up() if it wakes something up.
2180 If it doesn't wake anything up then a memory barrier may or may not be
2181 executed; you must not rely on it. The barrier occurs before the task state
2190 <general barrier> <general barrier>
2196 To repeat, a general memory barrier is guaranteed to be executed by wake_up()
2210 wake_up_process() always executes a general memory barrier. The barrier again
2284 On SMP systems locking primitives give a more substantial form of barrier: one
2416 The way to deal with this is to insert a general SMP memory barrier:
2425 In this case, the barrier makes a guarantee that all memory accesses before the
2426 barrier will appear to happen before all the memory accesses after the barrier
2428 the memory accesses before the barrier will be complete by the time the barrier
2432 compiler barrier, thus making sure the compiler emits the instructions in the
2756 A memory barrier isn't sufficient in such a case, but rather the cache must be
2818 barrier. For instance with the following code:
2862 since, without either a write barrier or an WRITE_ONCE(), it can be
2868 may, without a memory barrier or an READ_ONCE() and WRITE_ONCE(), be
2883 the data dependency barrier really becomes necessary as this synchronises both