Lines Matching +full:upside +full:- +full:down
20 ------------------------------------
31 2. Compilers are permitted to use the "as-if" rule. That is, a
33 as long as the results of a single-threaded execution appear
41 your full-ordering warranty, as do undersized accesses that load
51 holding the update-side lock, reads from that variable
62 -------
64 Locking is well-known and straightforward, at least if you don't think
153 Counter-intuitive though it might be, it is quite possible to have
188 sufficiently to rule out the counter-intuitive outcome.
195 load buffering, release-acquire chains, store buffering.
197 here: https://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test6.pdf
201 --------------------
205 but in the opposite order. The goal is to avoid the counter-intuitive
237 The init_stack_slab() function in lib/stackdepot.c uses release-acquire
239 the mutual-exclusion design is left as an exercise for the reader.
247 rcu_assign_pointer() and rcu_dereference() operate on RCU-protected
315 the following write-side code fragment:
317 log->l_curr_block -= log->l_logBBsize;
318 ASSERT(log->l_curr_block >= 0);
320 log->l_curr_cycle++;
323 the corresponding read-side code fragment:
325 cur_cycle = READ_ONCE(log->l_curr_cycle);
327 cur_block = READ_ONCE(log->l_curr_block);
334 * if (LOAD ->data_tail) { LOAD ->data_head
338 * STORE ->data_head STORE ->data_tail
351 -------------------
355 to the first. The goal is to avoid the counter-intuitive situation where
360 One way of avoiding the counter-intuitive outcome is through the use of a
381 The A/D pairing from the ring-buffer use case shown earlier also
389 * if (LOAD ->data_tail) { LOAD ->data_head
393 * STORE ->data_head STORE ->data_tail
398 The kernel's control dependency between the load from ->data_tail
400 between the load from data and the store to ->data_tail prevents
401 the counter-intuitive outcome where the kernel overwrites the data
405 Release-acquire chains
406 ----------------------
408 Release-acquire chains are a low-overhead, flexible, and easy-to-use
464 is that in this version, CPU2() is not part of the release-acquire chain.
467 Despite this limitation, release-acquire chains are low-overhead as
468 well as simple and powerful, at least as memory-ordering mechanisms go.
472 ---------------
474 Store buffering can be thought of as upside-down load buffering, so
496 this counter-intuitive outcome.
503 * CPU0 - waker CPU1 - waiter
531 1. Write-to-read, where the next CPU reads the value that the
532 previous CPU wrote. The LB litmus-test patterns contain only
533 this type of relation. In formal memory-modeling texts, this
534 relation is called "reads-from" and is usually abbreviated "rf".
536 2. Read-to-write, where the next CPU overwrites the value that the
538 of relation. In formal memory-modeling texts, this relation is
539 often called "from-reads" and is sometimes abbreviated "fr".
541 3. Write-to-write, where the next CPU overwrites the value written
543 write-to-write relation between the last access of CPU1() and
544 the first access of CPU2(). In formal memory-modeling texts,
550 avoid a counter-intuitive outcome depends on the types of relations
553 o If all links are write-to-read links, then the weakest
558 o If all but one of the links are write-to-read links, then a
559 release-acquire chain suffices. Both the MP and the ISA2
563 write-to-read links, then a full memory barrier is required
564 between each successive pair of non-write-to-read links. This
566 locking and in the release-acquire sections.