Lines Matching refs:P1
121 P1()
132 CPU and P1() represents the read() routine running on another. The
134 Thus, P0 stores the data in buf and then sets flag. Meanwhile, P1
153 A memory model will predict what values P1 might obtain for its loads
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
167 routines run concurrently. One possibility is that P1 runs after P0's
169 will again both be 0. (If P1 had been designed to read buf
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
235 P1()
271 X: P1 loads 1 from flag executes before
272 Y: P1 loads 0 from buf executes before
568 P1()
592 P1()
599 If r1 = 0x56781234 (little-endian!) at the end, then P1 must have read
700 P1()
715 READ_ONCE() in P1, on Itanium it sometimes could end up with r1 = 5
1140 P1()
1149 can malfunction on Alpha systems (notice that P1 uses an ordinary load
1154 smp_wmb() forces P0's store to x to propagate to P1 before the store
1155 to ptr does. And since P1 can't execute its second load
1157 first load, the value x = 1 must have propagated to P1 before the
1161 stores do reach P1's local cache in the proper order, it can happen
1164 value may not become available for P1's CPU to read until after the
1174 between P1's two loads when the kernel is compiled for the Alpha
1181 P1()
1190 then we would never get r1 = &x and r2 = 0. By the time P1 executed
1262 P1()
1272 event, because P1's store came after P0's store in x's coherence
1273 order, and P1's store propagated to P0 before P0's load executed.
1288 P1()
1298 because P1's store overwrote the value read by P0's first load, and
1299 P1's store propagated to P0 before P0's second load executed.
1314 P1()
1325 from P1's second load to its first (backwards!). The reason is
1326 similar to the previous examples: The value P1 loads from buf gets
1328 to buf will propagate to P1 before the store to flag does, and the
1329 store to flag propagates to P1 before P1 reads flag.
1332 P1 must execute its second load before the first. Indeed, if the load
1334 have propagated to P1 by the time P1's load from buf executed, so r2
1339 But what if we put an smp_rmb() fence between P1's loads? The fence
1366 P1()
1383 overwritten by P1's store since x = 2 at the end (a coe link), the
1384 smp_wmb() ensures that P1's store to x propagates to P2 before the
1454 P1()
1463 If r0 = 0 at the end then there is a pb link from P0's load to P1's
1464 load: an fre link from P0's load to P1's store (which overwrites the
1465 value read by P0), and a strong fence between P1's store and its load.
1470 Similarly, if r1 = 0 at the end then there is a pb link from P1's load
1523 P1()
1534 means that P0's store to x propagated to P1 before P1 called
1536 P1's grace period, contrary to part (2) of the Guarantee. On the
1538 end of the critical section, did not propagate to P1 before the end of
1733 P1()
1744 P1's load at W reads from, so we have W ->fre Y. Since S ->po W and
1748 If r1 = 1 at the end then P1's load at Z reads from P0's store at X,
1771 P1()
1798 P0 P1 P2
1816 section in P0 both starts before P1's grace period does and ends
1817 before it does, and the critical section in P2 both starts after P1's
1890 P1()
1942 P1()
1961 If r1 = 1 at the end then the spin_lock() in P1 must have read from
1964 if P1 had used a lock variable different from s, the writes could have
1966 P1 had all executed on a single CPU, as in the example before this
2008 P1()
2015 P1's store to x propagates to P0 before P0's load from x executes.
2031 NULL pointer, because P1's store to x might propagate to P0 after the
2143 P1()
2155 means that the store to buf must propagate from P0 to P1 before Z
2224 P1()
2245 at the machine level, must propagate to P1 before X's store to
2249 Y is a valid indicator that X propagated to P1 before Y
2254 The smp_rmb() fence in P1 is a compiler barrier as well as a
2260 Thus U's store to buf is forced to propagate to P1 before V's load
2341 P1()
2359 stores will propagate to P1 in that order. However, rcu_dereference()
2362 that the load of ptr in P1 is r-pre-bounded before the load of *p
2407 P1()
2415 Do the plain stores to y race? Clearly not if P1 reads a non-zero
2417 means that the read-side critical section in P1 must finish executing
2420 P1 before the critical section started and so would have been visible
2425 This means there is an rcu-fence link from P1's "y = 2" store to P0's
2426 "y = 3" store, and consequently the first must propagate from P1 to P0
2428 concurrent and there is no race, even though P1's plain store to y
2604 P1()
2615 you it is not, but the model won't mention that this is because P1