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
502 executes on a separate CPU before the main program runs.
576 x's cache line). We write W ->co W' if W comes before W' in the
583 Write-write coherence: If W ->po-loc W' (i.e., W comes before
592 is a store, then the store which R reads from must come before
597 store read by R comes before the store read by R' in the
637 rule: The READ_ONCE() load comes before the WRITE_ONCE() store in
659 would violate the read-read coherence rule: The r1 load comes before
717 the write which R reads from is co-before W. In symbols,
747 same location, that come before R in program order. If there are, it
781 the CPU to execute all po-earlier instructions before any
785 before any po-later loads;
788 before any po-later stores;
792 part of an smp_load_acquire()) before any po-later
796 execute all po-earlier instructions before the store
804 on C to propagate to C' before any po-later stores do.
806 For each other CPU C', any store which propagates to C before
808 stores executed on C) is forced to propagate to C' before the
811 Any store which propagates to C before a strong fence is
813 propagate to all other CPUs before any instructions po-after
817 affects stores from other CPUs that propagate to CPU C before the
818 fence is executed, as well as stores that are executed on C before the
822 executed on C before the fence (i.e., those which precede the fence in
840 F is a release fence and some X comes before F in program order,
848 before W' does. However, for different CPUs C and C', it does not
849 require W to propagate to C before W' propagates to C'.
858 value before it knows what that value is, among other things.
870 Happens-before: This requires that certain instructions are
885 memory models (such as those for C11/C++11). The "happens-before" and
906 X event comes before the Y event in the global ordering. The LKMM's
970 memory accesses with X ->po Y; then the CPU must execute X before Y if
996 a store W will force the CPU to execute R before W. This is very
998 store before it knows what value should be stored (in the case of a
1006 can always satisfy the second load speculatively before the first, and
1014 a particular location before it knows what that location is. However,
1028 this situation we know it is possible for the CPU to execute R' before
1030 cannot execute R' before R, because it cannot forward the value before
1033 and W then the CPU can speculatively forward W to R' before executing
1045 same location even before it knows what the location's address is.
1054 (the po-loc link says that R comes before W in program order and they
1062 and the CPU executed W' before W, then the memory subsystem would put
1063 W' before W in the coherence order. It would effectively cause W to
1103 smp_wmb() forces P0's store to x to propagate to P1 before the store
1106 first load, the value x = 1 must have propagated to P1 before the
1163 The happens-before relation (hb) links memory accesses that have to
1168 that W's store must have propagated to R's CPU before R executed;
1170 must have executed before R, and so we have W ->hb R.
1175 execute before W does.
1180 they execute on different CPUs, and W comes before W' in the coherence
1182 execute before W, because the decision as to which store overwrites
1188 has executed, which is possible if W executes shortly before R.
1195 the first event in the coherence order and propagates to C before the
1218 had executed before its store then the value of the store would have
1222 order, and P1's store propagated to P0 before P0's load executed.
1243 in program order. If the second load had executed before the first
1244 then the x = 9 store must have been propagated to P0 before the first
1248 P1's store propagated to P0 before P0's second load executed.
1277 to buf will propagate to P1 before the store to flag does, and the
1278 store to flag propagates to P1 before P1 reads flag.
1281 P1 must execute its second load before the first. Indeed, if the load
1293 Since an instruction can't execute before itself, we are forced to
1333 smp_wmb() ensures that P1's store to x propagates to P2 before the
1335 before P2's load and store execute, P2's smp_store_release()
1336 guarantees that the stores to x and y both propagate to P0 before the
1342 requirement is the content of the LKMM's "happens-before" axiom.
1353 The propagates-before (pb) relation capitalizes on the special
1356 before F executes. The formal definition requires that E be linked to
1370 propagate to Y's CPU before X does, hence before Y executes and hence
1371 before the strong fence executes. Because this fence is strong, we
1372 know that W will propagate to every CPU and to RAM before Z executes.
1373 And because of the hb links, we know that Z will execute before F.
1375 propagate to every CPU and to RAM before F executes.
1381 before F. To see why, suppose that F executed first. Then W would
1382 have propagated to E's CPU before E executed. If E was a store, the
1422 before itself. Thus, adding smp_mb() fences to the SB pattern
1449 (1) C ends before G does, and in addition, every store that
1450 propagates to C's CPU before the end of C must propagate to
1451 every CPU before G ends.
1453 (2) G starts before C does, and in addition, every store that
1454 propagates to G's CPU before the start of G must propagate
1455 to every CPU before C starts.
1458 before and end after a grace period.
1483 means that P0's store to x propagated to P1 before P1 called
1484 synchronize_rcu(), so P0's critical section must have started before
1486 other hand, r2 = 0 means that P0's store to y, which occurs before the
1487 end of the critical section, did not propagate to P1 before the end of
1494 starts before a grace period does then the critical section's CPU will
1496 some time before the grace period's synchronize_rcu() call returns.
1499 and some time before the critical section's opening rcu_read_lock()
1503 before" or "ends after" a grace period? Some aspects of the meaning
1507 "before": If E and F are RCU fence events (i.e., rcu_read_lock(),
1509 E ->rcu-link F includes cases where E is po-before some memory-access
1534 "before", then X ->rcu-gp Y ->rcu-link Z roughly says that X is a
1535 grace period which ends before Z begins. (In fact it covers more than
1537 Z's CPU before Z begins but doesn't propagate to some other CPU until
1539 the end of a critical section which starts before Z begins.
1559 particular, E ->rcu-order F implies not only that E begins before F
1560 ends, but also that any write po-before E will propagate to every CPU
1561 before any instruction po-after F can execute. (However, it does not
1562 imply that E must execute before F; in fact, each synchronize_rcu()
1573 1. G = W is po-before or equal to X;
1575 2. X comes "before" Y in some sense (including rfe, co and fr);
1577 3. Y is po-before Z;
1583 From 1 - 4 we deduce that the grace period G ends before the critical
1585 that G starts before C does, but also that any write which executes on
1586 G's CPU before G starts must propagate to every CPU before C starts.
1587 In particular, the write propagates to every CPU before F finishes
1588 executing and hence before any instruction po-after F can execute.
1604 executes before Y, but also (if X is a store) that X propagates to
1605 every CPU before Y executes. Thus rcu-fence is sort of a
1611 Finally, the LKMM defines the RCU-before (rb) relation in terms of
1615 before F, just as E ->pb F does (and for much the same reasons).
1629 violated: A critical section starts before a grace period, and some
1630 store propagates to the critical section's CPU before the end of the
1637 period. Saying that the critical section starts before S means there
1639 critical section), Q is "before" R in the sense used by the rcu-link
1640 relation, and R is po-before the grace period S. Thus we have:
1644 Let W be the store mentioned above, let Y come before the end of the
1739 If r0 = r1 = r2 = 1 at the end, then similar reasoning to before shows
1765 section in P0 both starts before P1's grace period does and ends
1766 before it does, and the critical section in P2 both starts after P1's
1817 requires that every instruction po-before the lock-release must
1818 execute before any instruction po-after the lock-acquire. This would
1846 therefore the load of x must execute before the load of y. Thus we
1873 and thus it could load y before x, obtaining r2 = 0 and r1 = 1.
1876 stores W and W' occur po-before the lock-release and po-after the
1878 each CPU before W' does. For example, consider:
1911 before the store to y does, so we cannot have r2 = 1 and r3 = 0.
1958 P1's store to x propagates to P0 before P0's load from x executes.
1975 test against NULL has been made but before the READ_ONCE() executes.
2019 If two memory accesses aren't concurrent then one must execute before
2022 (together referred to as xb, for "executes before"). However, there
2025 If X is a load and X executes before a store Y, then indeed there is
2030 store, then even if X executes before Y it is still possible that X
2036 requires not only that X must execute before Y but also that X must
2037 propagate to Y's CPU before Y executes. (Or vice versa, of course, if
2038 Y executes before X -- then Y must propagate to X's CPU before X
2060 cumul-fence memory barriers force stores that are po-before
2061 the barrier to propagate to other CPUs before stores that are
2066 R's CPU before R executed.
2068 strong-fence memory barriers force stores that are po-before
2069 the barrier, or that propagate to the barrier's CPU before the
2070 barrier executes, to propagate to all CPUs before any events
2098 means that the store to buf must propagate from P0 to P1 before Z
2100 provides an xb link from Z to Y (i.e., it forces Z to execute before
2101 Y). Therefore we have X ->vis Y: X must propagate to Y's CPU before Y
2141 corresponding to the first group of accesses will all end po-before
2186 access U, all those instructions will be po-before the fence.
2188 at the machine level, must propagate to P1 before X's store to
2192 Y is a valid indicator that X propagated to P1 before Y
2203 Thus U's store to buf is forced to propagate to P1 before V's load
2209 executes before some marked access E. We can do this by finding a
2268 *p; the marked load must execute before any of the machine
2301 is definitely w-post-bounded before the store to ptr, and the two
2305 that the load of ptr in P1 is r-pre-bounded before the load of *p
2331 could now perform the load of x before the load of ptr (there might be
2361 before the grace period in P0 does, because RCU's Grace-Period
2363 P1 before the critical section started and so would have been visible
2370 before the second can execute. Therefore the two stores cannot be
2409 happens-before, propagates-before, and rcu axioms (which state that
2424 executes before, even if one or both is plain).
2495 for this source code in which W' could execute before R. Just as with