Lines Matching refs:this
59 Warning: The code examples in this document are not written in the
80 specified values. Of course, this is just another way of expressing
145 Please note that this example code is a simplified abstraction. Real
168 store to buf but before the store to flag. In this case, r1 and r2
173 If this were to occur it would mean the driver contains a bug, because
175 happens, the LKMM does predict this outcome can occur, and the example
183 is Sequential Consistency. According to this model, systems behave as
194 goes like this:
209 Since an instruction (in this case, P0's store to flag) cannot
245 this outcome to occur, and in fact it does sometimes occur on x86 and
256 Memory models are all about ordering. Often this is temporal ordering
266 Z ordered before X, because this would mean that X is ordered before
346 Although this may seem straightforward, there is one subtle aspect to
367 than ordinary memory accesses. Thanks to this usage, we can be certain
397 For this code, the LKMM predicts that the load from x will always be
410 Given this version of the code, the LKMM would predict that the load
528 accesses are used. Consider this example:
562 ordering which all the CPUs agree on (the coherence order), and this
620 If the final value stored in x after this code ran was 17, you would
636 If r1 = 666 at the end, this would violate the read-write coherence
639 coming earlier in the coherence order (in this case, x's initial
658 imaginary store which establishes x's initial value) at the end, this
663 (As a minor curiosity, if this code had used normal loads instead of
755 (In fact, the picture needs to be a little more complicated than this.
764 discuss this in more detail later.)
819 fence. We describe this property by saying that release fences and
897 inserting the loads from that location into this ordering, by placing
904 and po-loc relations agree with this global ordering; in other words,
907 "coherence" axiom expresses this by requiring the union of these
927 this case) does not get altered between the read and the write events
940 In this example, CPU 0's increment effectively gets lost because it
947 to enforce atomicity the LKMM requires that atomic updates follow this
1017 section for more details). The kernel includes a workaround for this
1028 this situation we know it is possible for the CPU to execute R' before
1038 an address dependency like this:
1047 this.)
1066 allowing out-of-order writes like this to occur. The model avoided
1102 At first glance this doesn't seem to make sense. We know that the
1122 In practice, this difficulty is solved by inserting a special fence
1125 adds this fence after every READ_ONCE() and atomic load on Alpha. The
1147 share this property: They do not allow the CPU to execute any po-later
1156 And of course, none of this matters for any architecture other than
1199 like this:
1217 order. We can deduce this from the operational model; if P0's load
1220 8. In this case there is a prop link from P0's write event to its read
1245 load executed, and so r1 would have been 9 rather than 0. In this
1300 one fence, although this quickly leads to diminishing returns in terms
1330 If x = 2, r0 = 1, and r2 = 1 after this code runs then there is a prop
1359 links. Let's see how this definition works out.
1371 before the strong fence executes. Because this fence is strong, we
1415 In this example, the sequences of cumul-fence and hb links are empty.
1416 Note that this pb link is not included in hb as an instance of prop,
1440 be nested, although we won't make use of this fact.
1481 The Grace Period Guarantee tells us that when this code runs, it will
1505 entirely clear. The LKMM formalizes this notion by means of the
1530 that this relation is "inverted": It links the end of the
1536 this, because it also includes cases where some store propagates to
1548 would imply that X ->rcu-order V, because this sequence contains two
1565 To prove this in full generality requires some intellectual effort.
1603 From the discussion above, we see this implies not only that X
1608 CPUs. (Perhaps this fact should lead us to say that rcu-fence isn't
1617 Putting this all together, the LKMM expresses the Grace Period
1619 Equivalently, this "rcu" axiom requires that there are no events E
1648 some event X which is po-after S. Symbolically, this amounts to:
1653 at the time that Z executes. From this, it can be shown (see the
1661 From this we obtain:
1665 a forbidden cycle. Thus the "rcu" axiom rules out this violation of
1669 works out in practice. Consider the RCU code example from above, this
1698 so we have X ->rfe Z. Together with L ->po X and Z ->po S, this
1741 L2 ->rcu-link U0. However this cycle is not forbidden, because the
1784 However, this special code is intended to be more or less equivalent
1847 cannot have r1 = 1 and r2 = 0 at the end (this is an instance of the
1956 On the face of it, one would expect that when this code runs, the only
1963 like this:
1973 And now it is obvious that this code runs the risk of dereferencing a
1977 the compiler would not have performed this optimization and there
1980 Given the possibility of transformations like this one, the LKMM
2058 The motivations behind this definition are straightforward:
2073 To see how this works out in practice, consider our old friend, the MP
2106 are plain. Now, although we have not said so explicitly, up to this
2111 There are good reasons for this restriction. The compiler is not
2134 Given source code like this:
2209 executes before some marked access E. We can do this by finding a
2213 fence. We describe this arrangement by saying that R is
2239 For this reason, whenever the LKMM requires a plain store to be
2245 compiler has augmented a store with a load in this fashion, and the
2247 compiler if it ever did this. Still, better safe than sorry.)
2272 assumption like this one, some usages typical of RCU would count as
2295 (In this example the rcu_read_lock() and rcu_read_unlock() calls don't
2310 like this one. In particular, comparisons between the pointer and
2336 race-candidate access by a fence. At first glance this may seem
2374 Putting all this material together yields the following picture. For
2414 To this end, the LKMM imposes three extra restrictions, together
2438 contribute to the ppo relation), but at the moment it seems that this
2448 The descriptions in this document don't always match the formal
2493 ppo link from R to W'. The reasoning behind this is perhaps a little
2495 for this source code in which W' could execute before R. Just as with
2497 to undermine this relation if sufficient care is not taken.
2532 executions at all, which makes sense. But this can also lead to
2558 you it is not, but the model won't mention that this is because P1