Lines Matching refs:before
149 private variables before using them. All that is beside the point;
162 instance, P1 might run entirely before P0 begins, in which case r1 and
163 r2 will both be 0 at the end. Or P0 might run entirely before P1
168 store to buf but before the store to flag. In this case, r1 and r2
196 Since r1 = 1, P0 must store 1 to flag before P1 loads 1 from
199 P1 loads from flag before loading from buf, since CPUs execute
202 P1 must load 0 from buf before P0 stores 1 to it; otherwise r2
206 P0 stores 1 to buf before storing 1 to flag, since it executes
210 execute before itself, the specified outcome is impossible.
265 It's not possible to have X ordered before Y, Y ordered before Z, and
266 Z ordered before X, because this would mean that X is ordered before
270 W: P0 stores 1 to flag executes before
271 X: P1 loads 1 from flag executes before
272 Y: P1 loads 0 from buf executes before
273 Z: P0 stores 1 to buf executes before
335 that X is po-before Y (written as "X ->po Y" in formulas) if X occurs
336 before Y in the instruction stream.
343 first comes before the second in program order and they access the
398 executed before either of the stores to y. However, a compiler could
420 The object code might call f(5) either before or after g(6); the
526 Access beyond the end or before the beginning of an array is one kind
553 executes on a separate CPU before the main program runs.
627 x's cache line). We write W ->co W' if W comes before W' in the
634 Write-write coherence: If W ->po-loc W' (i.e., W comes before
643 is a store, then the store which R reads from must come before
648 store read by R comes before the store read by R' in the
688 rule: The READ_ONCE() load comes before the WRITE_ONCE() store in
710 would violate the read-read coherence rule: The r1 load comes before
768 the write which R reads from is co-before W. In symbols,
798 same location, that come before R in program order. If there are, it
832 the CPU to execute all po-earlier instructions before any
836 before any po-later loads;
839 before any po-later stores;
843 part of an smp_load_acquire()) before any po-later
847 execute all po-earlier instructions before the store
855 on C to propagate to C' before any po-later stores do.
857 For each other CPU C', any store which propagates to C before
859 stores executed on C) is forced to propagate to C' before the
862 Any store which propagates to C before a strong fence is
864 propagate to all other CPUs before any instructions po-after
868 affects stores from other CPUs that propagate to CPU C before the
869 fence is executed, as well as stores that are executed on C before the
873 executed on C before the fence (i.e., those which precede the fence in
891 F is a release fence and some X comes before F in program order,
899 before W' does. However, for different CPUs C and C', it does not
900 require W to propagate to C before W' propagates to C'.
909 value before it knows what that value is, among other things.
921 Happens-before: This requires that certain instructions are
936 memory models (such as those for C11/C++11). The "happens-before" and
957 X event comes before the Y event in the global ordering. The LKMM's
1021 memory accesses with X ->po Y; then the CPU must execute X before Y if
1047 a store W will force the CPU to execute R before W. This is very
1049 store before it knows what value should be stored (in the case of a
1057 can always satisfy the second load speculatively before the first, and
1065 a particular location before it knows what that location is. However,
1079 this situation we know it is possible for the CPU to execute R' before
1081 cannot execute R' before R, because it cannot forward the value before
1084 and W then the CPU can speculatively forward W to R' before executing
1096 same location even before it knows what the location's address is.
1105 (the po-loc link says that R comes before W in program order and they
1113 and the CPU executed W' before W, then the memory subsystem would put
1114 W' before W in the coherence order. It would effectively cause W to
1154 smp_wmb() forces P0's store to x to propagate to P1 before the store
1157 first load, the value x = 1 must have propagated to P1 before the
1214 The happens-before relation (hb) links memory accesses that have to
1219 that W's store must have propagated to R's CPU before R executed;
1221 must have executed before R, and so we have W ->hb R.
1226 execute before W does.
1231 they execute on different CPUs, and W comes before W' in the coherence
1233 execute before W, because the decision as to which store overwrites
1239 has executed, which is possible if W executes shortly before R.
1246 the first event in the coherence order and propagates to C before the
1269 had executed before its store then the value of the store would have
1273 order, and P1's store propagated to P0 before P0's load executed.
1294 in program order. If the second load had executed before the first
1295 then the x = 9 store must have been propagated to P0 before the first
1299 P1's store propagated to P0 before P0's second load executed.
1328 to buf will propagate to P1 before the store to flag does, and the
1329 store to flag propagates to P1 before P1 reads flag.
1332 P1 must execute its second load before the first. Indeed, if the load
1344 Since an instruction can't execute before itself, we are forced to
1384 smp_wmb() ensures that P1's store to x propagates to P2 before the
1386 before P2's load and store execute, P2's smp_store_release()
1387 guarantees that the stores to x and y both propagate to P0 before the
1393 requirement is the content of the LKMM's "happens-before" axiom.
1404 The propagates-before (pb) relation capitalizes on the special
1407 before F executes. The formal definition requires that E be linked to
1421 propagate to Y's CPU before X does, hence before Y executes and hence
1422 before the strong fence executes. Because this fence is strong, we
1423 know that W will propagate to every CPU and to RAM before Z executes.
1424 And because of the hb links, we know that Z will execute before F.
1426 propagate to every CPU and to RAM before F executes.
1432 before F. To see why, suppose that F executed first. Then W would
1433 have propagated to E's CPU before E executed. If E was a store, the
1473 before itself. Thus, adding smp_mb() fences to the SB pattern
1500 (1) C ends before G does, and in addition, every store that
1501 propagates to C's CPU before the end of C must propagate to
1502 every CPU before G ends.
1504 (2) G starts before C does, and in addition, every store that
1505 propagates to G's CPU before the start of G must propagate
1506 to every CPU before C starts.
1509 before and end after a grace period.
1534 means that P0's store to x propagated to P1 before P1 called
1535 synchronize_rcu(), so P0's critical section must have started before
1537 other hand, r2 = 0 means that P0's store to y, which occurs before the
1538 end of the critical section, did not propagate to P1 before the end of
1545 starts before a grace period does then the critical section's CPU will
1547 some time before the grace period's synchronize_rcu() call returns.
1550 and some time before the critical section's opening rcu_read_lock()
1554 before" or "ends after" a grace period? Some aspects of the meaning
1558 "before": If E and F are RCU fence events (i.e., rcu_read_lock(),
1560 E ->rcu-link F includes cases where E is po-before some memory-access
1585 "before", then X ->rcu-gp Y ->rcu-link Z roughly says that X is a
1586 grace period which ends before Z begins. (In fact it covers more than
1588 Z's CPU before Z begins but doesn't propagate to some other CPU until
1590 the end of a critical section which starts before Z begins.
1610 particular, E ->rcu-order F implies not only that E begins before F
1611 ends, but also that any write po-before E will propagate to every CPU
1612 before any instruction po-after F can execute. (However, it does not
1613 imply that E must execute before F; in fact, each synchronize_rcu()
1624 1. G = W is po-before or equal to X;
1626 2. X comes "before" Y in some sense (including rfe, co and fr);
1628 3. Y is po-before Z;
1634 From 1 - 4 we deduce that the grace period G ends before the critical
1636 that G starts before C does, but also that any write which executes on
1637 G's CPU before G starts must propagate to every CPU before C starts.
1638 In particular, the write propagates to every CPU before F finishes
1639 executing and hence before any instruction po-after F can execute.
1655 executes before Y, but also (if X is a store) that X propagates to
1656 every CPU before Y executes. Thus rcu-fence is sort of a
1662 Finally, the LKMM defines the RCU-before (rb) relation in terms of
1666 before F, just as E ->pb F does (and for much the same reasons).
1680 violated: A critical section starts before a grace period, and some
1681 store propagates to the critical section's CPU before the end of the
1688 period. Saying that the critical section starts before S means there
1690 critical section), Q is "before" R in the sense used by the rcu-link
1691 relation, and R is po-before the grace period S. Thus we have:
1695 Let W be the store mentioned above, let Y come before the end of the
1790 If r0 = r1 = r2 = 1 at the end, then similar reasoning to before shows
1816 section in P0 both starts before P1's grace period does and ends
1817 before it does, and the critical section in P2 both starts after P1's
1868 the LKMM requires that every instruction po-before the lock-release
1869 must execute before any instruction po-after the lock-acquire. This
1898 therefore the load of x must execute before the load of y, even though
1925 and thus it could load y before x, obtaining r2 = 0 and r1 = 1.
1928 and some other stores W and W' occur po-before the lock-release and
1930 propagate to each CPU before W' does. For example, consider:
1963 before the store to y does, so we cannot have r2 = 1 and r3 = 0. But
1966 P1 had all executed on a single CPU, as in the example before this
2015 P1's store to x propagates to P0 before P0's load from x executes.
2032 test against NULL has been made but before the READ_ONCE() executes.
2076 If two memory accesses aren't concurrent then one must execute before
2079 (together referred to as xb, for "executes before"). However, there
2082 If X is a load and X executes before a store Y, then indeed there is
2087 store, then even if X executes before Y it is still possible that X
2093 requires not only that X must execute before Y but also that X must
2094 propagate to Y's CPU before Y executes. (Or vice versa, of course, if
2095 Y executes before X -- then Y must propagate to X's CPU before X
2117 cumul-fence memory barriers force stores that are po-before
2118 the barrier to propagate to other CPUs before stores that are
2123 R's CPU before R executed.
2125 strong-fence memory barriers force stores that are po-before
2126 the barrier, or that propagate to the barrier's CPU before the
2127 barrier executes, to propagate to all CPUs before any events
2155 means that the store to buf must propagate from P0 to P1 before Z
2157 provides an xb link from Z to Y (i.e., it forces Z to execute before
2158 Y). Therefore we have X ->vis Y: X must propagate to Y's CPU before Y
2198 corresponding to the first group of accesses will all end po-before
2243 access U, all those instructions will be po-before the fence.
2245 at the machine level, must propagate to P1 before X's store to
2249 Y is a valid indicator that X propagated to P1 before Y
2260 Thus U's store to buf is forced to propagate to P1 before V's load
2266 executes before some marked access E. We can do this by finding a
2325 *p; the marked load must execute before any of the machine
2358 is definitely w-post-bounded before the store to ptr, and the two
2362 that the load of ptr in P1 is r-pre-bounded before the load of *p
2388 could now perform the load of x before the load of ptr (there might be
2418 before the grace period in P0 does, because RCU's Grace-Period
2420 P1 before the critical section started and so would have been visible
2427 before the second can execute. Therefore the two stores cannot be
2466 happens-before, propagates-before, and rcu axioms (which state that
2481 executes before, even if one or both is plain).
2552 for this source code in which W' could execute before R. Just as with