Lines Matching refs:before
150 private variables before using them. All that is beside the point;
163 instance, P1 might run entirely before P0 begins, in which case r1 and
164 r2 will both be 0 at the end. Or P0 might run entirely before P1
169 store to buf but before the store to flag. In this case, r1 and r2
197 Since r1 = 1, P0 must store 1 to flag before P1 loads 1 from
200 P1 loads from flag before loading from buf, since CPUs execute
203 P1 must load 0 from buf before P0 stores 1 to it; otherwise r2
207 P0 stores 1 to buf before storing 1 to flag, since it executes
211 execute before itself, the specified outcome is impossible.
266 It's not possible to have X ordered before Y, Y ordered before Z, and
267 Z ordered before X, because this would mean that X is ordered before
271 W: P0 stores 1 to flag executes before
272 X: P1 loads 1 from flag executes before
273 Y: P1 loads 0 from buf executes before
274 Z: P0 stores 1 to buf executes before
336 that X is po-before Y (written as "X ->po Y" in formulas) if X occurs
337 before Y in the instruction stream.
344 first comes before the second in program order and they access the
399 executed before either of the stores to y. However, a compiler could
421 The object code might call f(5) either before or after g(6); the
528 Access beyond the end or before the beginning of an array is one kind
555 executes on a separate CPU before the main program runs.
629 x's cache line). We write W ->co W' if W comes before W' in the
636 Write-write coherence: If W ->po-loc W' (i.e., W comes before
645 is a store, then the store which R reads from must come before
650 store read by R comes before the store read by R' in the
690 rule: The READ_ONCE() load comes before the WRITE_ONCE() store in
712 would violate the read-read coherence rule: The r1 load comes before
770 the write which R reads from is co-before W. In symbols,
800 same location, that come before R in program order. If there are, it
834 the CPU to execute all po-earlier instructions before any
838 before any po-later loads;
841 before any po-later stores;
845 part of an smp_load_acquire()) before any po-later
849 execute all po-earlier instructions before the store
857 on C to propagate to C' before any po-later stores do.
859 For each other CPU C', any store which propagates to C before
861 stores executed on C) is forced to propagate to C' before the
864 Any store which propagates to C before a strong fence is
866 propagate to all other CPUs before any instructions po-after
870 affects stores from other CPUs that propagate to CPU C before the
871 fence is executed, as well as stores that are executed on C before the
875 executed on C before the fence (i.e., those which precede the fence in
893 F is a release fence and some X comes before F in program order,
901 before W' does. However, for different CPUs C and C', it does not
902 require W to propagate to C before W' propagates to C'.
911 value before it knows what that value is, among other things.
923 Happens-before: This requires that certain instructions are
938 memory models (such as those for C11/C++11). The "happens-before" and
959 X event comes before the Y event in the global ordering. The LKMM's
1029 to each CPU before the store X does. Then the fact that X and Y are
1031 before Y does. In an analogous way, rmw sequences can also extend
1053 memory accesses with X ->po Y; then the CPU must execute X before Y if
1079 a store W will force the CPU to execute R before W. This is very
1081 store before it knows what value should be stored (in the case of a
1089 can always satisfy the second load speculatively before the first, and
1097 a particular location before it knows what that location is. However,
1111 this situation we know it is possible for the CPU to execute R' before
1113 cannot execute R' before R, because it cannot forward the value before
1116 and W then the CPU can speculatively forward W to R' before executing
1128 same location even before it knows what the location's address is.
1137 (the po-loc link says that R comes before W in program order and they
1145 and the CPU executed W' before W, then the memory subsystem would put
1146 W' before W in the coherence order. It would effectively cause W to
1186 smp_wmb() forces P0's store to x to propagate to P1 before the store
1189 first load, the value x = 1 must have propagated to P1 before the
1246 The happens-before relation (hb) links memory accesses that have to
1251 that W's store must have propagated to R's CPU before R executed;
1253 must have executed before R, and so we have W ->hb R.
1258 execute before W does.
1263 they execute on different CPUs, and W comes before W' in the coherence
1265 execute before W, because the decision as to which store overwrites
1271 has executed, which is possible if W executes shortly before R.
1278 the first event in the coherence order and propagates to C before the
1301 had executed before its store then the value of the store would have
1305 order, and P1's store propagated to P0 before P0's load executed.
1326 in program order. If the second load had executed before the first
1327 then the x = 9 store must have been propagated to P0 before the first
1331 P1's store propagated to P0 before P0's second load executed.
1360 to buf will propagate to P1 before the store to flag does, and the
1361 store to flag propagates to P1 before P1 reads flag.
1364 P1 must execute its second load before the first. Indeed, if the load
1376 Since an instruction can't execute before itself, we are forced to
1416 smp_wmb() ensures that P1's store to x propagates to P2 before the
1418 before P2's load and store execute, P2's smp_store_release()
1419 guarantees that the stores to x and y both propagate to P0 before the
1425 requirement is the content of the LKMM's "happens-before" axiom.
1436 The propagates-before (pb) relation capitalizes on the special
1439 before F executes. The formal definition requires that E be linked to
1453 propagate to Y's CPU before X does, hence before Y executes and hence
1454 before the strong fence executes. Because this fence is strong, we
1455 know that W will propagate to every CPU and to RAM before Z executes.
1456 And because of the hb links, we know that Z will execute before F.
1458 propagate to every CPU and to RAM before F executes.
1464 before F. To see why, suppose that F executed first. Then W would
1465 have propagated to E's CPU before E executed. If E was a store, the
1505 before itself. Thus, adding smp_mb() fences to the SB pattern
1532 (1) C ends before G does, and in addition, every store that
1533 propagates to C's CPU before the end of C must propagate to
1534 every CPU before G ends.
1536 (2) G starts before C does, and in addition, every store that
1537 propagates to G's CPU before the start of G must propagate
1538 to every CPU before C starts.
1541 before and end after a grace period.
1566 means that P0's store to x propagated to P1 before P1 called
1567 synchronize_rcu(), so P0's critical section must have started before
1569 other hand, r2 = 0 means that P0's store to y, which occurs before the
1570 end of the critical section, did not propagate to P1 before the end of
1577 starts before a grace period does then the critical section's CPU will
1579 some time before the grace period's synchronize_rcu() call returns.
1582 and some time before the critical section's opening rcu_read_lock()
1586 before" or "ends after" a grace period? Some aspects of the meaning
1590 "before": If E and F are RCU fence events (i.e., rcu_read_lock(),
1592 E ->rcu-link F includes cases where E is po-before some memory-access
1617 "before", then X ->rcu-gp Y ->rcu-link Z roughly says that X is a
1618 grace period which ends before Z begins. (In fact it covers more than
1620 Z's CPU before Z begins but doesn't propagate to some other CPU until
1622 the end of a critical section which starts before Z begins.
1642 particular, E ->rcu-order F implies not only that E begins before F
1643 ends, but also that any write po-before E will propagate to every CPU
1644 before any instruction po-after F can execute. (However, it does not
1645 imply that E must execute before F; in fact, each synchronize_rcu()
1656 1. G = W is po-before or equal to X;
1658 2. X comes "before" Y in some sense (including rfe, co and fr);
1660 3. Y is po-before Z;
1666 From 1 - 4 we deduce that the grace period G ends before the critical
1668 that G starts before C does, but also that any write which executes on
1669 G's CPU before G starts must propagate to every CPU before C starts.
1670 In particular, the write propagates to every CPU before F finishes
1671 executing and hence before any instruction po-after F can execute.
1687 executes before Y, but also (if X is a store) that X propagates to
1688 every CPU before Y executes. Thus rcu-fence is sort of a
1694 Finally, the LKMM defines the RCU-before (rb) relation in terms of
1698 before F, just as E ->pb F does (and for much the same reasons).
1712 violated: A critical section starts before a grace period, and some
1713 store propagates to the critical section's CPU before the end of the
1720 period. Saying that the critical section starts before S means there
1722 critical section), Q is "before" R in the sense used by the rcu-link
1723 relation, and R is po-before the grace period S. Thus we have:
1727 Let W be the store mentioned above, let Y come before the end of the
1822 If r0 = r1 = r2 = 1 at the end, then similar reasoning to before shows
1848 section in P0 both starts before P1's grace period does and ends
1849 before it does, and the critical section in P2 both starts after P1's
2055 the LKMM requires that every instruction po-before the lock-release
2056 must execute before any instruction po-after the lock-acquire. This
2085 therefore the load of x must execute before the load of y, even though
2112 and thus it could load y before x, obtaining r2 = 0 and r1 = 1.
2115 and some other stores W and W' occur po-before the lock-release and
2117 propagate to each CPU before W' does. For example, consider:
2150 before the store to y does, so we cannot have r2 = 1 and r3 = 0. But
2153 P1 had all executed on a single CPU, as in the example before this
2202 P1's store to x propagates to P0 before P0's load from x executes.
2219 test against NULL has been made but before the READ_ONCE() executes.
2263 If two memory accesses aren't concurrent then one must execute before
2266 (together referred to as xb, for "executes before"). However, there
2269 If X is a load and X executes before a store Y, then indeed there is
2274 store, then even if X executes before Y it is still possible that X
2280 requires not only that X must execute before Y but also that X must
2281 propagate to Y's CPU before Y executes. (Or vice versa, of course, if
2282 Y executes before X -- then Y must propagate to X's CPU before X
2304 cumul-fence memory barriers force stores that are po-before
2305 the barrier to propagate to other CPUs before stores that are
2310 R's CPU before R executed.
2312 strong-fence memory barriers force stores that are po-before
2313 the barrier, or that propagate to the barrier's CPU before the
2314 barrier executes, to propagate to all CPUs before any events
2342 means that the store to buf must propagate from P0 to P1 before Z
2344 provides an xb link from Z to Y (i.e., it forces Z to execute before
2345 Y). Therefore we have X ->vis Y: X must propagate to Y's CPU before Y
2385 corresponding to the first group of accesses will all end po-before
2430 access U, all those instructions will be po-before the fence.
2432 at the machine level, must propagate to P1 before X's store to
2436 Y is a valid indicator that X propagated to P1 before Y
2447 Thus U's store to buf is forced to propagate to P1 before V's load
2453 executes before some marked access E. We can do this by finding a
2512 *p; the marked load must execute before any of the machine
2545 is definitely w-post-bounded before the store to ptr, and the two
2549 that the load of ptr in P1 is r-pre-bounded before the load of *p
2575 could now perform the load of x before the load of ptr (there might be
2605 before the grace period in P0 does, because RCU's Grace-Period
2607 P1 before the critical section started and so would have been visible
2614 before the second can execute. Therefore the two stores cannot be
2653 happens-before, propagates-before, and rcu axioms (which state that
2668 executes before, even if one or both is plain).
2739 for this source code in which W' could execute before R. Just as with