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 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
881 memory models (such as those for C11/C++11). The "happens-before" and
902 X event comes before the Y event in the global ordering. The LKMM's
966 memory accesses with X ->po Y; then the CPU must execute X before Y if
992 a store W will force the CPU to execute R before W. This is very
994 store before it knows what value should be stored (in the case of a
1002 can always satisfy the second load speculatively before the first, and
1010 a particular location before it knows what that location is. However,
1024 this situation we know it is possible for the CPU to execute R' before
1026 cannot execute R' before R, because it cannot forward the value before
1029 and W then the CPU can speculatively forward W to R' before executing
1041 same location even before it knows what the location's address is.
1050 (the po-loc link says that R comes before W in program order and they
1058 and the CPU executed W' before W, then the memory subsystem would put
1059 W' before W in the coherence order. It would effectively cause W to
1099 smp_wmb() forces P0's store to x to propagate to P1 before the store
1102 first load, the value x = 1 must have propagated to P1 before the
1161 The happens-before relation (hb) links memory accesses that have to
1166 that W's store must have propagated to R's CPU before R executed;
1168 must have executed before R, and so we have W ->hb R.
1173 execute before W does.
1178 they execute on different CPUs, and W comes before W' in the coherence
1180 execute before W, because the decision as to which store overwrites
1186 has executed, which is possible if W executes shortly before R.
1193 the first event in the coherence order and propagates to C before the
1216 had executed before its store then the value of the store would have
1220 order, and P1's store propagated to P0 before P0's load executed.
1241 in program order. If the second load had executed before the first
1242 then the x = 9 store must have been propagated to P0 before the first
1246 P1's store propagated to P0 before P0's second load executed.
1275 to buf will propagate to P1 before the store to flag does, and the
1276 store to flag propagates to P1 before P1 reads flag.
1279 P1 must execute its second load before the first. Indeed, if the load
1291 Since an instruction can't execute before itself, we are forced to
1331 smp_wmb() ensures that P1's store to x propagates to P2 before the
1333 before P2's load and store execute, P2's smp_store_release()
1334 guarantees that the stores to x and y both propagate to P0 before the
1340 requirement is the content of the LKMM's "happens-before" axiom.
1351 The propagates-before (pb) relation capitalizes on the special
1354 before F executes. The formal definition requires that E be linked to
1368 propagate to Y's CPU before X does, hence before Y executes and hence
1369 before the strong fence executes. Because this fence is strong, we
1370 know that W will propagate to every CPU and to RAM before Z executes.
1371 And because of the hb links, we know that Z will execute before F.
1373 propagate to every CPU and to RAM before F executes.
1379 before F. To see why, suppose that F executed first. Then W would
1380 have propagated to E's CPU before E executed. If E was a store, the
1420 before itself. Thus, adding smp_mb() fences to the SB pattern
1447 (1) C ends before G does, and in addition, every store that
1448 propagates to C's CPU before the end of C must propagate to
1449 every CPU before G ends.
1451 (2) G starts before C does, and in addition, every store that
1452 propagates to G's CPU before the start of G must propagate
1453 to every CPU before C starts.
1456 before and end after a grace period.
1481 means that P0's store to x propagated to P1 before P1 called
1482 synchronize_rcu(), so P0's critical section must have started before
1484 other hand, r2 = 0 means that P0's store to y, which occurs before the
1485 end of the critical section, did not propagate to P1 before the end of
1492 starts before a grace period does then the critical section's CPU will
1494 some time before the grace period's synchronize_rcu() call returns.
1497 and some time before the critical section's opening rcu_read_lock()
1501 before" or "ends after" a grace period? Some aspects of the meaning
1505 "before": If E and F are RCU fence events (i.e., rcu_read_lock(),
1507 E ->rcu-link F includes cases where E is po-before some memory-access
1532 "before", then X ->rcu-gp Y ->rcu-link Z roughly says that X is a
1533 grace period which ends before Z begins. (In fact it covers more than
1535 Z's CPU before Z begins but doesn't propagate to some other CPU until
1537 the end of a critical section which starts before Z begins.
1557 E ->rcu-fence F implies not only that E begins before F ends, but also
1558 that any write po-before E will propagate to every CPU before any
1560 E must execute before F; in fact, each synchronize_rcu() fence event
1571 1. G = W is po-before or equal to X;
1573 2. X comes "before" Y in some sense (including rfe, co and fr);
1575 2. Y is po-before Z;
1581 From 1 - 4 we deduce that the grace period G ends before the critical
1583 that G starts before C does, but also that any write which executes on
1584 G's CPU before G starts must propagate to every CPU before C starts.
1585 In particular, the write propagates to every CPU before F finishes
1586 executing and hence before any instruction po-after F can execute.
1590 Finally, the LKMM defines the RCU-before (rb) relation in terms of
1594 before F, just as E ->pb F does (and for much the same reasons).
1608 violated: A critical section starts before a grace period, and some
1609 store propagates to the critical section's CPU before the end of the
1616 period. Saying that the critical section starts before S means there
1618 critical section), Q is "before" R in the sense used by the rcu-link
1619 relation, and R is po-before the grace period S. Thus we have:
1623 Let W be the store mentioned above, let Y come before the end of the
1718 If r0 = r1 = r2 = 1 at the end, then similar reasoning to before shows
1744 section in P0 both starts before P1's grace period does and ends
1745 before it does, and the critical section in P2 both starts after P1's
1796 requires that every instruction po-before the lock-release must
1797 execute before any instruction po-after the lock-acquire. This would
1825 therefore the load of x must execute before the load of y. Thus we
1852 and thus it could load y before x, obtaining r2 = 0 and r1 = 1.
1855 stores W and W' occur po-before the lock-release and po-after the
1857 each CPU before W' does. For example, consider:
1890 before the store to y does, so we cannot have r2 = 1 and r3 = 0.