Lines Matching refs:READ_ONCE
197 WRITE_ONCE(Q, P); smp_read_barrier_depends(); D = READ_ONCE(*Q);
204 does nothing, but it is required for DEC Alpha. The READ_ONCE()
212 a = READ_ONCE(*X); WRITE_ONCE(*X, b);
220 WRITE_ONCE(*X, c); d = READ_ONCE(*X);
232 with memory references that are not protected by READ_ONCE() and
524 Q = READ_ONCE(P);
551 Q = READ_ONCE(P);
578 Q = READ_ONCE(P);
599 q = READ_ONCE(a);
602 p = READ_ONCE(b);
611 q = READ_ONCE(a);
614 p = READ_ONCE(b);
620 q = READ_ONCE(a);
626 said, please note that READ_ONCE() is not optional! Without the
627 READ_ONCE(), the compiler might combine the load from 'a' with other
639 So don't leave out the READ_ONCE().
644 q = READ_ONCE(a);
658 q = READ_ONCE(a);
676 q = READ_ONCE(a);
688 q = READ_ONCE(a);
697 The initial READ_ONCE() is still required to prevent the compiler from
704 q = READ_ONCE(a);
717 q = READ_ONCE(a);
728 q = READ_ONCE(a);
745 q = READ_ONCE(a);
753 q = READ_ONCE(a);
757 out-guess your code. More generally, although READ_ONCE() does force
767 r1 = READ_ONCE(x); r2 = READ_ONCE(y);
811 away the ordering. Careful use of READ_ONCE() and WRITE_ONCE()
815 dependency into nonexistence. Careful use of READ_ONCE() or
844 WRITE_ONCE(b, 2); x = READ_ONCE(b);
846 y = READ_ONCE(a);
854 WRITE_ONCE(b, &a); x = READ_ONCE(b);
862 r1 = READ_ONCE(y);
864 WRITE_ONCE(y, 1); if (r2 = READ_ONCE(x)) {
880 WRITE_ONCE(a, 1); }---- --->{ v = READ_ONCE(c);
881 WRITE_ONCE(b, 2); } \ / { w = READ_ONCE(d);
883 WRITE_ONCE(c, 3); } / \ { x = READ_ONCE(a);
884 WRITE_ONCE(d, 4); }---- --->{ y = READ_ONCE(b);
1335 variants of barrier(). However, READ_ONCE() and WRITE_ONCE() can be
1337 accesses flagged by the READ_ONCE() or WRITE_ONCE().
1349 The READ_ONCE() and WRITE_ONCE() functions can prevent any number of
1365 a[0] = READ_ONCE(x);
1366 a[1] = READ_ONCE(x);
1368 In short, READ_ONCE() and WRITE_ONCE() provide cache coherence for
1386 Use READ_ONCE() to prevent the compiler from doing this to you:
1388 while (tmp = READ_ONCE(a))
1410 Again, use READ_ONCE() to prevent the compiler from doing this:
1412 while (tmp = READ_ONCE(a))
1436 compiler's proof will be erroneous. Use READ_ONCE() to tell the
1439 while (tmp = READ_ONCE(a))
1443 do with the value after the READ_ONCE(). For example, suppose you
1446 while ((tmp = READ_ONCE(a)) % MAX)
1515 if (READ_ONCE(flag))
1516 process_message(READ_ONCE(msg));
1519 Note that the READ_ONCE() and WRITE_ONCE() wrappers in
1522 for example, a nested interrupt or an NMI. Otherwise, READ_ONCE()
1529 You should assume that the compiler can move READ_ONCE() and
1530 WRITE_ONCE() past code not containing READ_ONCE(), WRITE_ONCE(),
1533 This effect could also be achieved using barrier(), but READ_ONCE()
1534 and WRITE_ONCE() are more selective: With READ_ONCE() and
1539 respect the order in which the READ_ONCE()s and WRITE_ONCE()s occur,
1569 poor performance and scalability. Use READ_ONCE() to prevent
1607 Because there are no READ_ONCE() or WRITE_ONCE() wrappers and no
1611 load tearing on 'foo1.b' and store tearing on 'foo2.b'. READ_ONCE()
1615 WRITE_ONCE(foo2.b, READ_ONCE(foo1.b));
1618 All that aside, it is never necessary to use READ_ONCE() and
1621 say READ_ONCE(jiffies). The reason for this is that READ_ONCE() and
1652 has not yet been reached about these problems, however the READ_ONCE()
2829 a = READ_ONCE(*A);
2831 c = READ_ONCE(*C);
2832 d = READ_ONCE(*D);
2880 U = READ_ONCE(*A);
2883 X = READ_ONCE(*A);
2885 Z = READ_ONCE(*A);
2902 of the world remains consistent. Note that READ_ONCE() and WRITE_ONCE()
2905 On such architectures, READ_ONCE() and WRITE_ONCE() do whatever is
2907 used by READ_ONCE() and WRITE_ONCE() cause GCC to emit the special ld.acq
2928 may, without a memory barrier or an READ_ONCE() and WRITE_ONCE(), be