Lines Matching refs:ordering

89  (*) Assumed minimum execution ordering model.
139 abstract CPU, memory operation ordering is very relaxed, and a CPU may actually
367 ordering over the memory operations on either side of the barrier.
389      A write barrier is a partial ordering on stores only; it is not required
409      A data dependency barrier is a partial ordering on interdependent loads
423      showing the ordering constraints.
443      A read barrier is a partial ordering on loads only; it is not required to
460      A general memory barrier is a partial ordering over both loads and stores.
646 of dependency ordering is to -prevent- writes to the data structure, along
649 naturally occurring ordering prevents such records from being lost.
652 Note well that the ordering provided by a data dependency is local to
695 However, stores are not speculated.  This means that ordering -is- provided
708 Either can result in highly counterintuitive effects on ordering.
720 It is tempting to try to enforce ordering on identical stores on both
739 	WRITE_ONCE(b, 1);  /* BUG: No ordering vs. load from a!!! */
752 Therefore, if you need ordering in this example, you need explicit
765 ordering is guaranteed only when the stores differ, for example:
800 Given this transformation, the CPU is not required to respect the ordering
804 relying on this ordering, you should make sure that MAX is greater than
850 	WRITE_ONCE(c, 1);  /* BUG: No ordering against the read from 'a'. */
852 It is tempting to argue that there in fact is ordering because the
874 Note well that the ordering provided by a control dependency is local
882       However, they do -not- guarantee any other sort of ordering:
884       later anything.  If you need these other forms of ordering,
901       away the ordering.  Careful use of READ_ONCE() and WRITE_ONCE()
1164 then the partial ordering imposed by CPU 1 will be perceived correctly by CPU
1358 Multicopy atomicity is a deeply intuitive notion about ordering that is
1422 but can also generate additional ordering that can ensure that -all-
1424 chain of release-acquire pairs do not provide this additional ordering,
1471 However, the ordering provided by a release-acquire chain is local
1492 In particular, it simply reads from its argument with ordering.  It does
1501 To reiterate, if your code requires full ordering of all operations,
1836 barrier.  Data dependencies do not impose any additional compiler ordering.
1853 [!] Note that SMP memory barriers _must_ be used to control the ordering of
1900      These are for use with consistent memory to guarantee the ordering
2080 Locks and semaphores may not provide any guarantee of ordering on UP compiled
2236 In terms of memory ordering, these functions all provide the same guarantees of
2288 that does affect memory access ordering on other CPUs, within the context of
2506 CPU, that CPU's dependency ordering logic will take care of everything else.
2545      required to enforce ordering.
2578 address register if ordering rules are sufficiently relaxed:
2583 If ordering rules are relaxed, it must be assumed that accesses done inside an
2596 likely, then interrupt-disabling locks should be used to guarantee ordering.
2657      ordering guarantees.  Specifically, they do not guarantee ordering with
2659      ordering with respect to LOCK or UNLOCK operations.  If the latter is
2978  (*) the CPU's data cache may affect the ordering, and whilst cache-coherency