Lines Matching +full:test +full:- +full:rules
8 and the third section provides a few rules of thumb.
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
34 just as if the compiler had followed all the relevant rules.
41 your full-ordering warranty, as do undersized accesses that load
51 holding the update-side lock, reads from that variable
62 -------
66 locklessly accessing lock-protected shared variables.
68 Locking is well-known and straightforward, at least if you don't think
100 following litmus test:
157 Counter-intuitive though it might be, it is quite possible to have
192 sufficiently to rule out the counter-intuitive outcome.
199 load buffering, release-acquire chains, store buffering.
201 here: https://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test6.pdf
205 --------------------
209 but in the opposite order. The goal is to avoid the counter-intuitive
213 in the MP+poonceonces.litmus litmus test. This section therefore looks at
241 The init_stack_slab() function in lib/stackdepot.c uses release-acquire
243 the mutual-exclusion design is left as an exercise for the reader.
251 rcu_assign_pointer() and rcu_dereference() operate on RCU-protected
319 the following write-side code fragment:
321 log->l_curr_block -= log->l_logBBsize;
322 ASSERT(log->l_curr_block >= 0);
324 log->l_curr_cycle++;
327 the corresponding read-side code fragment:
329 cur_cycle = READ_ONCE(log->l_curr_cycle);
331 cur_block = READ_ONCE(log->l_curr_block);
338 * if (LOAD ->data_tail) { LOAD ->data_head
342 * STORE ->data_head STORE ->data_tail
355 -------------------
359 to the first. The goal is to avoid the counter-intuitive situation where
362 can be seen in the LB+poonceonces.litmus litmus test.
364 One way of avoiding the counter-intuitive outcome is through the use of a
385 The A/D pairing from the ring-buffer use case shown earlier also
393 * if (LOAD ->data_tail) { LOAD ->data_head
397 * STORE ->data_head STORE ->data_tail
402 The kernel's control dependency between the load from ->data_tail
404 between the load from data and the store to ->data_tail prevents
405 the counter-intuitive outcome where the kernel overwrites the data
409 Release-acquire chains
410 ----------------------
412 Release-acquire chains are a low-overhead, flexible, and easy-to-use
468 is that in this version, CPU2() is not part of the release-acquire chain.
469 This situation is accounted for in the rules of thumb below.
471 Despite this limitation, release-acquire chains are low-overhead as
472 well as simple and powerful, at least as memory-ordering mechanisms go.
476 ---------------
478 Store buffering can be thought of as upside-down load buffering, so
500 this counter-intuitive outcome.
507 * CPU0 - waker CPU1 - waiter
527 Rules of thumb
533 given litmus test. There are three types of linkage:
535 1. Write-to-read, where the next CPU reads the value that the
536 previous CPU wrote. The LB litmus-test patterns contain only
537 this type of relation. In formal memory-modeling texts, this
538 relation is called "reads-from" and is usually abbreviated "rf".
540 2. Read-to-write, where the next CPU overwrites the value that the
541 previous CPU read. The SB litmus test contains only this type
542 of relation. In formal memory-modeling texts, this relation is
543 often called "from-reads" and is sometimes abbreviated "fr".
545 3. Write-to-write, where the next CPU overwrites the value written
546 by the previous CPU. The Z6.0 litmus test pattern contains a
547 write-to-write relation between the last access of CPU1() and
548 the first access of CPU2(). In formal memory-modeling texts,
553 The strength of memory ordering required for a given litmus test to
554 avoid a counter-intuitive outcome depends on the types of relations
557 o If all links are write-to-read links, then the weakest
559 the LB litmus test, a control dependency was enough to do the
562 o If all but one of the links are write-to-read links, then a
563 release-acquire chain suffices. Both the MP and the ISA2
567 write-to-read links, then a full memory barrier is required
568 between each successive pair of non-write-to-read links. This
570 locking and in the release-acquire sections.
572 However, if you find yourself having to stretch these rules of thumb
573 to fit your situation, you should consider creating a litmus test and