Lines Matching refs:Y
265 It's not possible to have X ordered before Y, Y ordered before Z, and
272 Y: P1 loads 0 from 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.
905 whenever we have X ->rf Y or X ->co Y or X ->fr Y or X ->po-loc Y, the
906 X event comes before the Y event in the global ordering. The LKMM's
969 situation: Fences are a source of ppo links. Suppose X and Y are
970 memory accesses with X ->po Y; then the CPU must execute X before Y if
974 X and Y;
976 X and Y are both stores and an smp_wmb() fence occurs between
979 X and Y are both loads and an smp_rmb() fence occurs between
984 Y is also a release fence, such as smp_store_release().
989 X and Y are both loads, X ->addr Y (i.e., there is an address
990 dependency from X to Y), and X is a READ_ONCE() or an atomic
1362 of links begins with coe). Then there are events W, X, Y, and Z such
1365 E ->coe W ->cumul-fence* X ->rfe? Y ->strong-fence Z ->hb* F,
1368 specified type, and the ? suffix indicates the link is optional (Y may
1370 propagate to Y's CPU before X does, hence before Y executes and hence
1510 event X, F is po-after some memory-access event Y, and we have any of
1511 X ->rfe Y, X ->co Y, or X ->fr Y.
1534 "before", then X ->rcu-gp Y ->rcu-link Z roughly says that X is a
1538 after X ends.) Similarly, X ->rcu-rscsi Y ->rcu-link Z says that X is
1546 X ->rcu-gp Y ->rcu-link Z ->rcu-rscsi T ->rcu-link U ->rcu-gp V
1552 X ->rcu-rscsi Y ->rcu-link Z ->rcu-rscsi T ->rcu-link U ->rcu-gp V
1571 and there are events X, Y and a read-side critical section C such that:
1575 2. X comes "before" Y in some sense (including rfe, co and fr);
1577 3. Y is po-before Z;
1598 like strong fences). Written symbolically, X ->rcu-fence Y means
1601 X ->po E ->rcu-order F ->po Y.
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
1644 Let W be the store mentioned above, let Y come before the end of the
1650 S ->po X ->hb* Z ->fr W ->rf Y ->po U.
1678 Y: WRITE_ONCE(y, 1);
1692 If r2 = 0 at the end then P0's store at Y overwrites the value that
1693 P1's load at W reads from, so we have W ->fre Y. Since S ->po W and
1694 also Y ->po U, we get S ->rcu-link U. In addition, S ->rcu-gp S
2025 If X is a load and X executes before a store Y, then indeed there is
2026 no danger of X and Y being concurrent. After all, Y can't have any
2028 propagated Y from its own CPU to X's CPU, which won't happen until
2029 some time after Y executes and thus after X executes. But if X is a
2030 store, then even if X executes before Y it is still possible that X
2031 will propagate to Y's CPU just as Y is executing. In such a case X
2032 could very well interfere somehow with Y, and we would have to
2033 consider X and Y to be concurrent.
2035 Therefore when X is a store, for X and Y to be non-concurrent the LKMM
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
2039 executes if Y is a store.) This is expressed by the visibility
2040 relation (vis), where X ->vis Y is defined to hold if there is an
2049 Z is connected to Y by a strong-fence link followed by a
2054 Z is on the same CPU as Y and is connected to Y by a possibly
2056 means Z and Y are the same event).
2093 Y: r2 = READ_ONCE(buf);
2099 executes. Next, Z and Y are on the same CPU and the smp_rmb() fence
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
2172 Y: r1 = READ_ONCE(flag);
2191 X and Y are both marked accesses. Hence an rfe link from X to
2192 Y is a valid indicator that X propagated to P1 before Y
2193 executed, i.e., X ->vis Y. (And if there is no rfe link then
2201 after the fence does and hence after Y does.
2212 marked access Y such that X ->xb* Y, and Y and E are ordered by a
2214 "post-bounded" by X and E is "pre-bounded" by Y.
2218 "w-pre-bounded" by Y, depending on whether E was a store or a load.