Lines Matching refs:X
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
272 X: P1 loads 1 from flag executes before
336 that X is po-before Y (written as "X ->po Y" in formulas) if X occurs
468 Finally, a read event X and a write event Y are linked by a control
470 X affects the evaluation of the if condition via a data or address
484 come earlier in program order. Symbolically, if we have R ->data X,
485 R ->addr X, or R ->ctrl X (where R is a read event), then we must also
486 have R ->po X. It wouldn't make sense for a computation to depend
893 F is a release fence and some X comes before F in program order,
894 where either X = E or else E ->rf X; or
896 A strong fence event occurs between some X and F in program
897 order, where either X = E or else E ->rf X.
958 whenever we have X ->rf Y or X ->co Y or X ->fr Y or X ->po-loc Y, the
959 X event comes before the Y event in the global ordering. The LKMM's
1006 (R ->rmw W) implies (there is no X with R ->fr X and X ->co W),
1025 U ->cumul-fence X -> rmw-sequence Y
1028 operational model, U ->cumul-fence X says that the store U propagates
1029 to each CPU before the store X does. Then the fact that X and Y are
1052 situation: Fences are a source of ppo links. Suppose X and Y are
1053 memory accesses with X ->po Y; then the CPU must execute X before Y if
1057 X and Y;
1059 X and Y are both stores and an smp_wmb() fence occurs between
1062 X and Y are both loads and an smp_rmb() fence occurs between
1065 X is also an acquire fence, such as smp_load_acquire();
1072 X and Y are both loads, X ->addr Y (i.e., there is an address
1073 dependency from X to Y), and X is a READ_ONCE() or an atomic
1445 of links begins with coe). Then there are events W, X, Y, and Z such
1448 E ->coe W ->cumul-fence* X ->rfe? Y ->strong-fence Z ->hb* F,
1452 be equal to X). Because of the cumul-fence links, we know that W will
1453 propagate to Y's CPU before X does, hence before Y executes and hence
1593 event X, F is po-after some memory-access event Y, and we have any of
1594 X ->rfe Y, X ->co Y, or X ->fr Y.
1617 "before", then X ->rcu-gp Y ->rcu-link Z roughly says that X is a
1621 after X ends.) Similarly, X ->rcu-rscsi Y ->rcu-link Z says that X is
1629 X ->rcu-gp Y ->rcu-link Z ->rcu-rscsi T ->rcu-link U ->rcu-gp V
1631 would imply that X ->rcu-order V, because this sequence contains two
1633 X ->rcu-order T and Z ->rcu-order V.) On the other hand:
1635 X ->rcu-rscsi Y ->rcu-link Z ->rcu-rscsi T ->rcu-link U ->rcu-gp V
1637 does not imply X ->rcu-order V, because the sequence contains only
1654 and there are events X, Y and a read-side critical section C such that:
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);
1681 like strong fences). Written symbolically, X ->rcu-fence Y means
1684 X ->po E ->rcu-order F ->po Y.
1686 From the discussion above, we see this implies not only that X
1687 executes before Y, but also (if X is a store) that X propagates to
1731 some event X which is po-after S. Symbolically, this amounts to:
1733 S ->po X ->hb* Z ->fr W ->rf Y ->po U.
1760 X: WRITE_ONCE(x, 1);
1780 If r1 = 1 at the end then P1's load at Z reads from P0's store at X,
1781 so we have X ->rfe Z. Together with L ->po X and Z ->po S, this
2269 If X is a load and X executes before a store Y, then indeed there is
2270 no danger of X and Y being concurrent. After all, Y can't have any
2271 effect on the value obtained by X until the memory subsystem has
2272 propagated Y from its own CPU to X's CPU, which won't happen until
2273 some time after Y executes and thus after X executes. But if X is a
2274 store, then even if X executes before Y it is still possible that X
2275 will propagate to Y's CPU just as Y is executing. In such a case X
2277 consider X and Y to be concurrent.
2279 Therefore when X is a store, for X and Y to be non-concurrent the LKMM
2280 requires not only that X must execute before Y but also that X must
2282 Y executes before X -- then Y must propagate to X's CPU before X
2284 relation (vis), where X ->vis Y is defined to hold if there is an
2287 X is connected to Z by a possibly empty sequence of
2289 these links are present, X and Z are the same event),
2325 X: WRITE_ONCE(buf, 1);
2340 The smp_wmb() memory barrier gives a cumul-fence link from X to W, and
2345 Y). Therefore we have X ->vis Y: X must propagate to Y's CPU before Y
2408 X: WRITE_ONCE(flag, 1);
2432 at the machine level, must propagate to P1 before X's store to
2435 X and Y are both marked accesses. Hence an rfe link from X to
2436 Y is a valid indicator that X propagated to P1 before Y
2437 executed, i.e., X ->vis Y. (And if there is no rfe link then
2454 marked access X such that R and X are ordered by a suitable fence and
2455 X ->xb* E. If E was also a plain access, we would also look for a
2456 marked access Y such that X ->xb* Y, and Y and E are ordered by a
2458 "post-bounded" by X and E is "pre-bounded" by Y.
2461 "r-post-bounded" by X. Similarly, E would be "r-pre-bounded" or
2467 above were a marked load then X could simply be taken to be R itself.)
2746 loaded originally by R. Thus, if R' is linked to any access X by a
2747 dependency, R is also linked to access X by the same dependency, even