Lines Matching refs:barrier
17 - Varieties of memory barrier.
21 - SMP barrier pairing.
22 - Examples of memory barrier sequences.
28 - Compiler barrier.
30 - MMIO write barrier.
39 (*) Inter-CPU locking barrier effects.
51 (*) Kernel I/O barrier effects.
327 ordering over the memory operations on either side of the barrier.
344 A write memory barrier gives a guarantee that all the STORE operations
345 specified before the barrier will appear to happen before all the STORE
346 operations specified after the barrier with respect to the other
349 A write barrier is a partial ordering on stores only; it is not required
353 memory system as time progresses. All stores before a write barrier will
354 occur in the sequence _before_ all the stores after the write barrier.
357 dependency barriers; see the "SMP barrier pairing" subsection.
362 A data dependency barrier is a weaker form of read barrier. In the case
365 load will be directed), a data dependency barrier would be required to
369 A data dependency barrier is a partial ordering on interdependent loads
375 considered can then perceive. A data dependency barrier issued by the CPU
378 time the barrier completes, the effects of all the stores prior to that
380 dependency barrier.
382 See the "Examples of memory barrier sequences" subsection for diagrams
389 a full read barrier or better is required. See the "Control dependencies"
393 write barriers; see the "SMP barrier pairing" subsection.
398 A read barrier is a data dependency barrier plus a guarantee that all the
399 LOAD operations specified before the barrier will appear to happen before
400 all the LOAD operations specified after the barrier with respect to the
403 A read barrier is a partial ordering on loads only; it is not required to
410 see the "SMP barrier pairing" subsection.
415 A general memory barrier gives a guarantee that all the LOAD and STORE
416 operations specified before the barrier will appear to happen before all
417 the LOAD and STORE operations specified after the barrier with respect to
420 A general memory barrier is a partial ordering over both loads and stores.
430 This acts as a one-way permeable barrier. It guarantees that all memory
445 This also acts as a one-way permeable barrier. It guarantees that all
455 for other sorts of memory barrier (but note the exceptions mentioned in
456 the subsection "MMIO write barrier"). In addition, a RELEASE+ACQUIRE
457 pair is -not- guaranteed to act as a full memory barrier. However, after
485 memory barrier will be _complete_ by the completion of a memory barrier
486 instruction; the barrier can be considered to draw a line in that CPU's
489 (*) There is no guarantee that issuing a memory barrier on one CPU will have
496 barrier, unless the first CPU _also_ uses a matching memory barrier (see
501 mechanisms should propagate the indirect effects of a memory barrier
522 <write barrier>
542 To deal with this, a data dependency barrier or better must be inserted
549 <write barrier>
552 <data dependency barrier>
576 <write barrier>
579 <data dependency barrier>
583 The data dependency barrier is very important to the RCU system,
595 A load-load control dependency requires a full read memory barrier, not
596 simply a data dependency barrier to make it work correctly. Consider the
601 <data dependency barrier> /* BUG: No data dependency!!! */
613 <read barrier>
646 barrier();
650 barrier();
659 barrier();
723 tempting to add a barrier(), but this does not help. The conditional
724 is gone, and the barrier won't bring it back. Therefore, if you are
802 to the same variable, a barrier() statement is required at the
814 barrier() can help to preserve your control dependency. Please
826 When dealing with CPU-CPU interactions, certain types of memory barrier should
830 other types of barriers, albeit without transitivity. An acquire barrier
831 pairs with a release barrier, but both may also pair with other barriers,
832 including of course general barriers. A write barrier pairs with a data
833 dependency barrier, a control dependency, an acquire barrier, a release
834 barrier, a read barrier, or a general barrier. Similarly a read barrier,
835 control dependency, or a data dependency barrier pairs with a write
836 barrier, an acquire barrier, a release barrier, or a general barrier:
841 <write barrier>
843 <read barrier>
851 <write barrier>
853 <data dependency barrier>
861 <general barrier>
869 Basically, the read barrier always has to be there, even though it can be of
872 [!] Note that the stores before the write barrier would normally be expected to
873 match the loads after the read barrier or the data dependency barrier, and vice
880 <write barrier> \ <read barrier>
896 <write barrier>
913 | | wwwwwwwwwwwwwwww } <--- At this point the write barrier
915 | | : | E=5 | } barrier to be committed before
934 <write barrier>
940 effectively random order, despite the write barrier issued by CPU 1:
972 If, however, a data dependency barrier were to be placed between the load of C
980 <write barrier>
983 <data dependency barrier>
1013 And thirdly, a read barrier acts as a partial order on loads. Consider the
1020 <write barrier>
1026 some effectively random order, despite the write barrier issued by CPU 1:
1049 If, however, a read barrier were to be placed between the load of B and the
1056 <write barrier>
1059 <read barrier>
1079 barrier causes all effects \ +-------+ | |
1086 contained a load of A either side of the read barrier:
1092 <write barrier>
1096 <read barrier>
1119 barrier causes all effects \ +-------+ | |
1126 before the read barrier completes anyway:
1197 Placing a read barrier or a data dependency barrier just before the second
1205 <read barrier>
1209 dependent on the type of barrier used. If there was no change made to the
1264 <general barrier> <general barrier>
1285 For example, suppose that CPU 2's general barrier in the above example
1286 is changed to a read barrier as shown below:
1292 <read barrier> <general barrier>
1299 The key point is that although CPU 2's read barrier orders its pair
1317 (*) Compiler barrier.
1321 (*) MMIO write barrier.
1327 The Linux kernel has an explicit compiler barrier function that prevents the
1330 barrier();
1332 This is a general barrier -- there are no read-read or write-write variants
1333 of barrier(). However, ACCESS_ONCE() can be thought of as a weak form
1334 for barrier() that affects only the specific accesses flagged by the
1337 The barrier() function has the following effects:
1340 barrier() to precede any accesses preceding the barrier().
1526 code not containing ACCESS_ONCE(), barrier(), or similar primitives.
1528 This effect could also be achieved using barrier(), but ACCESS_ONCE()
1530 the contents of the indicated memory locations, while with barrier()
1636 barrier. Data dependencies do not impose any additional compiler ordering.
1663 There are some more advanced barrier functions:
1668 barrier after it, depending on the function. It isn't guaranteed to
1669 insert anything more than a compiler barrier in a UP compilation.
1741 The Linux kernel also has a special barrier for use with memory-mapped I/O
1746 This is a variation on the mandatory write barrier that causes writes to weakly
1815 locks do not imply any sort of barrier.
1821 An ACQUIRE followed by a RELEASE may not be assumed to be full memory barrier
1839 RELEASE may -not- be assumed to be a full memory barrier.
1842 imply a full memory barrier. If it is necessary for a RELEASE-ACQUIRE
1843 pair to produce a full barrier, the ACQUIRE can be followed by an
1844 smp_mb__after_unlock_lock() invocation. This will produce a full barrier
1882 a memory barrier, which will force the earlier unlock operation
1915 See also the section on "Inter-CPU locking barrier effects".
1972 A general memory barrier is interpolated automatically by set_current_state()
1980 <general barrier>
1988 which therefore also imply a general memory barrier after setting the state.
1990 interpolate the memory barrier in the right place:
2012 A write memory barrier is implied by wake_up() and co. if and only if they wake
2013 something up. The barrier occurs before the task state is cleared, and so sits
2020 STORE current->state <write barrier>
2021 <general barrier> STORE current->state
2024 To repeat, this write memory barrier is present if and only if something
2033 wake_up(); load from Y sees 1, no memory barrier
2106 On SMP systems locking primitives give a more substantial form of barrier: one
2341 The way to deal with this is to insert a general SMP memory barrier:
2350 In this case, the barrier makes a guarantee that all memory accesses before the
2351 barrier will appear to happen before all the memory accesses after the barrier
2353 the memory accesses before the barrier will be complete by the time the barrier
2357 compiler barrier, thus making sure the compiler emits the instructions in the
2371 about the state (old or new) implies an SMP-conditional general memory barrier
2396 such the implicit memory barrier effects are necessary.
2408 With these the appropriate explicit memory barrier should be used if necessary
2427 sufficient references to make the lock, and thus a memory barrier unnecessary.
2446 [!] Note that special memory barrier primitives are available for these
2448 barriers, and so barrier instructions are superfluous in conjunction with them,
2449 and in such cases the special barrier primitives will be no-ops.
2582 Used with prefetchable I/O memory, an mmiowb() barrier may be required to
2594 required, an mmiowb() barrier can be used. Note that relaxed accesses to
2748 Imagine, then, that two writes are made on the first CPU, with a write barrier
2762 The write memory barrier forces the other CPUs in the system to perceive that
2798 To intervene, we need to interpolate a data dependency barrier or a read
2799 barrier between the loads. This will force the cache to commit its coherency
2822 Whilst most CPUs do imply a data dependency barrier on the read when a memory
2861 A memory barrier isn't sufficient in such a case, but rather the cache must be
2923 barrier. For instance with the following code:
2966 since, without either a write barrier or an ACCESS_ONCE(), it can be
2972 may, without a memory barrier or an ACCESS_ONCE(), be reduced to:
2986 the data dependency barrier really becomes necessary as this synchronises both
2990 The Alpha defines the Linux kernel's memory barrier model.