1 .\" $NetBSD: mb.9,v 1.4 2007/12/01 19:59:05 wiz Exp $
3 .\" Copyright (c) 2007 The NetBSD Foundation, Inc.
4 .\" All rights reserved.
6 .\" This code is derived from software contributed to The NetBSD Foundation
9 .\" Redistribution and use in source and binary forms, with or without
10 .\" modification, are permitted provided that the following conditions
12 .\" 1. Redistributions of source code must retain the above copyright
13 .\" notice, this list of conditions and the following disclaimer.
14 .\" 2. Redistributions in binary form must reproduce the above copyright
15 .\" notice, this list of conditions and the following disclaimer in the
16 .\" documentation and/or other materials provided with the distribution.
18 .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
19 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
20 .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
21 .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
22 .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
23 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
24 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
25 .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
26 .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
27 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
28 .\" POSSIBILITY OF SUCH DAMAGE.
48 Many types of processor can execute instructions in a different order
49 than issued by the compiler or assembler.
50 On a uniprocessor system, out of order execution is transparent
51 to the programmer, operating system and applications, as the processor
52 must ensure that it is self consistent.
54 On multiprocessor systems, out of order execution can present a
55 problem where locks are not used to guarantee atomicity of
56 access, because loads and stores issued by any given processor
57 can appear on the system bus (and thus appear to other processors)
58 in an unpredictable order.
64 can be used to control the order in which memory accesses occur, and
65 thus the order in which those accesses become visible to other processors.
66 They can be used to implement
68 access to data structures where
69 the necessary barrier conditions are well understood.
71 Memory barriers can be computationally expensive, as they are
74 operations and may stall further execution
75 until the processor has drained internal buffers and re-synchronized.
77 The memory barrier primitives control only the order of memory access.
78 They provide no guarantee that stores have been flushed to the bus, or
79 that loads have been made from the bus.
81 The memory barrier primitives are guaranteed only to prevent reordering
82 of accesses to main memory.
83 They do not provide any guarantee of ordering when used with device
84 memory (for example, loads or stores to or from a PCI device).
85 To guarantee ordering of access to device memory, the
89 interfaces should be used.
94 Issue a full memory barrier, ordering all memory accesses.
95 Causes all loads and stores preceding the call to
97 to complete before further memory accesses can be made.
100 Issue a read memory barrier, ordering all loads from memory.
101 Causes all loads preceding the call to
103 to complete before further loads can be made.
104 Stores may be reordered ahead of or behind a call to
108 Issue a write memory barrier, ordering all stores to memory.
109 Causes all stores preceding the call to
111 to complete before further stores can be made.
112 Loads may be reordered ahead of or behind a call to
121 The memory barrier primitives first appeared in