Lines Matching refs:other
303 each other.
308 structure declaration and the other is not, or if the two
329 Such enforcement is important because the CPUs and other devices in a system
346 operations specified after the barrier with respect to the other
373 As mentioned in (1), the other CPUs in the system can be viewed as
401 other components of the system.
418 the other components of the system.
432 ACQUIRE operation with respect to the other components of the system.
447 before the RELEASE operation with respect to the other components of the
455 for other sorts of memory barrier (but note the exceptions mentioned in
459 RELEASE on that same variable are guaranteed to be visible. In other
490 any direct effect on another CPU or any other hardware in the system. The
560 even-numbered cache lines and the other bank processes odd-numbered cache
607 by attempting to predict the outcome in advance, so that other CPUs see
625 Control dependencies pair normally with other types of barriers. That
627 READ_ONCE(), the compiler might combine the load from 'a' with other
628 loads from 'a', and the store to 'b' with other stores to 'b', with
797 However, they do -not- guarantee any other sort of ordering:
799 later anything. If you need these other forms of ordering,
819 (*) Control dependencies pair normally with other types of barriers.
831 General barriers pair with each other, though they also pair with most
832 other types of barriers, albeit without transitivity. An acquire barrier
833 pairs with a release barrier, but both may also pair with other barriers,
1163 other loads, and so do the load in advance - even though they haven't actually
1330 compiler from moving the memory accesses either side of it to the other side:
1407 a was modified by some other CPU between the "while" statement and
1467 surprise if some other CPU might have stored to variable 'a' in the
1523 and WRITE_ONCE() are not needed in interrupt_handler() other than
1558 could cause some other CPU to see a spurious value of 42 -- even
1709 object lifetime is handled by some mechanism other than RCU, for
1776 Some of the other functions in the linux kernel imply memory barriers, amongst
1939 other means.
2096 that does affect memory access ordering on other CPUs, within the context of
2116 through *H occur in, other than the constraints imposed by the separate locks
2255 In other words, it has to perform this sequence of events:
2283 Woken up by other event
2307 with respect to the other CPUs on the system. It does _not_ guarantee that all
2398 preference to other operations when implementing locking primitives, because
2443 two parts of the driver may interfere with each other's attempts to control or
2484 running on separate CPUs that communicate with each other. If such a case is
2512 They are guaranteed to be fully ordered with respect to each other.
2514 They are not guaranteed to be fully ordered with respect to other types of
2520 respect to each other on the issuing CPU depends on the characteristics
2551 other.
2573 instruction may proceed; in other words: provided that the appearance of
2628 other CPUs are concerned since the cache coherency mechanisms will migrate the
2640 the order in which the effects are perceived to happen by the other observers
2646 [!] MMIO or other device accesses may bypass the cache system. This depends on
2658 become apparent in the same order on those other CPUs.
2692 (*) whilst the CPU core is interrogating one cache, the other cache may be
2717 The write memory barrier forces the other CPUs in the system to perceive that
2729 the update to the cacheline holding v is delayed in the other of the second
2730 CPU's caches by some other cache event:
2866 order to other CPUs.