Lines Matching refs:to
21 properties except to the extent that they interact with an
48 a device driver, which must correctly order accesses to a physical
74 smp_mb(); // Order store to x before load from y.
77 All CPUs will agree that the store to "x" happened before the load
79 memory-ordering primitives. It is surprisingly hard to remember their
87 as cmpxchg() are only guaranteed to provide ordering when they succeed.
91 1. All code that executed prior to the RMW atomic operation.
119 typically instead used to provide ordering against RCU read-side critical
121 need a synchronize_rcu() to interact with readers, it costs you nothing
122 to also rely on its additional full-memory-barrier semantics. Just please
132 full ordering for these primitives. One way to obtain full ordering on
133 all architectures is to add a call to smp_mb():
146 smp_mb__after_atomic(); // Order store to x before load from y.
155 to an unordered RMW atomic operation.
158 ordering subsequent to an unordered RMW atomic operation.
161 to a successful spinlock acquisition. Note that spin_lock() is
165 subsequent to an srcu_read_unlock().
167 It is bad practice to place code between the smp__*() primitive and the
170 to another.
183 Then any given CPU will see the write to "x" has having happened before
184 the write to "y". However, you are usually better off using a release
187 Note that smp_wmb() might fail to provide ordering for unmarked C-language
189 value being overwritten is almost always equal to the new value. Such a
190 compiler might then reasonably decide to transform "x = 1" and "y = 1"
199 Therefore, if you need to use smp_wmb() with unmarked C-language writes,
200 you will need to make sure that none of the compilers used to build
226 used to prevent the compiler from moving code across an infinite loop:
233 Without the barrier(), the compiler would be within its rights to move the
234 WRITE_ONCE() to follow the loop. This code motion could be problematic
236 to handle this is to use READ_ONCE() for the load of "dontstop".
265 improved readability and performance compared to explicit barriers.
266 For example, use of smp_store_release() saves a line compared to the
272 More important, smp_store_release() makes it easier to connect up the
273 different pieces of the concurrent algorithm. The variable stored to
278 from "x" instead of writing to it. Then an smp_wmb() could not guarantee
288 to a simple load instruction followed by a simple store instruction.
289 In contrast, the smp_mb() compiles to an expensive instruction that
299 smp_store_release() except that: (1) It takes the pointer to
300 be assigned to instead of a pointer to that pointer, (2) It
301 is intended to be used in conjunction with rcu_dereference()
310 as cmpxchg_release() are only guaranteed to provide ordering
324 and readability compared to explicit barriers. For example, use of
325 smp_load_acquire() saves a line compared to the smp_rmb() example above:
330 As with smp_store_release(), this also makes it easier to connect
332 smp_store_release() that stores to "y". In addition, smp_load_acquire()
347 such as atomic_cmpxchg_acquire() are only guaranteed to provide
378 Compared to locking primitives and RMW atomic operations, markers
383 The way this works is that if a given call to synchronize_rcu() cannot
384 prove that it started before a given call to rcu_read_lock(), then
392 from the value loaded. There is said to be an *address dependency*
394 to that subsequent memory access.
396 A call to rcu_dereference() for a given RCU-protected pointer is
397 usually paired with a call to rcu_assign_pointer() for that same pointer
398 in much the same way that a call to smp_load_acquire() is paired with
399 a call to smp_store_release(). Calls to rcu_dereference() and
408 Documentation/RCU/rcu_dereference.rst. It can also be quite helpful to
416 through an "if" condition to a marked store (WRITE_ONCE() or stronger)
421 In short, you can use a control dependency to enforce ordering between
430 the write to "b".
434 all of the compilers used to build the Linux kernel. Please see the
451 Unordered operations to different variables are just that, unordered.
452 However, if a group of CPUs apply these operations to a single variable,
460 primitives require the compiler to emit the corresponding store
465 operations, unless these operations are to the same variable.
468 primitives require the compiler to emit the corresponding load
473 operations, unless these operations are to the same variable.
481 concurrent atomic_inc() operations applied to a given variable
498 Unmarked C-language accesses are normal variable accesses to normal
499 variables, that is, to variables that are not "volatile" and are not
507 Unmarked C-language accesses are unordered, and are also subject to
509 concurrent code. It is possible to use unmarked C-language accesses for
510 shared variables that are subject to concurrent access, but great care
514 C-language accesses requires careful attention to not just your code,
515 but to all the compilers that might be used to build it. Such compilers
523 o Guard all accesses to a given variable by a particular lock,
524 so that there are never concurrent conflicting accesses to
526 (1) at least one of the concurrent accesses to a variable is an
533 o Use locking or other means to ensure that all concurrent accesses
534 to a given variable are reads.
536 o Restrict use of a given variable to statistics or heuristics
544 If you need to live more dangerously, please do take the time to
545 understand the compilers. One place to start is these two LWN
555 to your compiler as new versions come out and as new optimizations