lock.h revision 1.14.22.2 1 /* $NetBSD: lock.h,v 1.14.22.2 2007/11/11 16:47:01 joerg Exp $ */
2
3 /*-
4 * Copyright (c) 2000, 2006 The NetBSD Foundation, Inc.
5 * All rights reserved.
6 *
7 * This code is derived from software contributed to The NetBSD Foundation
8 * by Jason R. Thorpe and Andrew Doran.
9 *
10 * Redistribution and use in source and binary forms, with or without
11 * modification, are permitted provided that the following conditions
12 * are met:
13 * 1. Redistributions of source code must retain the above copyright
14 * notice, this list of conditions and the following disclaimer.
15 * 2. Redistributions in binary form must reproduce the above copyright
16 * notice, this list of conditions and the following disclaimer in the
17 * documentation and/or other materials provided with the distribution.
18 * 3. All advertising materials mentioning features or use of this software
19 * must display the following acknowledgement:
20 * This product includes software developed by the NetBSD
21 * Foundation, Inc. and its contributors.
22 * 4. Neither the name of The NetBSD Foundation nor the names of its
23 * contributors may be used to endorse or promote products derived
24 * from this software without specific prior written permission.
25 *
26 * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
27 * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
28 * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
29 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
30 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
31 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
32 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
33 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
34 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
35 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
36 * POSSIBILITY OF SUCH DAMAGE.
37 */
38
39 /*
40 * Machine-dependent spin lock operations.
41 */
42
43 #ifndef _X86_LOCK_H_
44 #define _X86_LOCK_H_
45
46 #ifdef _KERNEL
47 #include <machine/cpufunc.h>
48 #endif
49 #include <machine/atomic.h>
50
51
52 static __inline int
53 __SIMPLELOCK_LOCKED_P(__cpu_simple_lock_t *__ptr)
54 {
55 return *__ptr == __SIMPLELOCK_LOCKED;
56 }
57
58 static __inline int
59 __SIMPLELOCK_UNLOCKED_P(__cpu_simple_lock_t *__ptr)
60 {
61 return *__ptr == __SIMPLELOCK_UNLOCKED;
62 }
63
64 static __inline void
65 __cpu_simple_lock_set(__cpu_simple_lock_t *__ptr)
66 {
67
68 *__ptr = __SIMPLELOCK_LOCKED;
69 }
70
71 static __inline void
72 __cpu_simple_lock_clear(__cpu_simple_lock_t *__ptr)
73 {
74
75 *__ptr = __SIMPLELOCK_UNLOCKED;
76 }
77
78 static __inline void __cpu_simple_lock_init(__cpu_simple_lock_t *)
79 __attribute__((__unused__));
80 static __inline void __cpu_simple_lock(__cpu_simple_lock_t *)
81 __attribute__((__unused__));
82 static __inline int __cpu_simple_lock_try(__cpu_simple_lock_t *)
83 __attribute__((__unused__));
84 static __inline void __cpu_simple_unlock(__cpu_simple_lock_t *)
85 __attribute__((__unused__));
86
87 static __inline void
88 __cpu_simple_lock_init(__cpu_simple_lock_t *lockp)
89 {
90
91 *lockp = __SIMPLELOCK_UNLOCKED;
92 __insn_barrier();
93 }
94
95 static __inline void
96 __cpu_simple_lock(__cpu_simple_lock_t *lockp)
97 {
98
99 while (x86_atomic_testset_b(lockp, __SIMPLELOCK_LOCKED)
100 != __SIMPLELOCK_UNLOCKED) {
101 do {
102 #ifdef _KERNEL
103 x86_pause();
104 #endif /* _KERNEL */
105 } while (*lockp == __SIMPLELOCK_LOCKED);
106 }
107 __insn_barrier();
108 }
109
110 static __inline int
111 __cpu_simple_lock_try(__cpu_simple_lock_t *lockp)
112 {
113 int r = (x86_atomic_testset_b(lockp, __SIMPLELOCK_LOCKED)
114 == __SIMPLELOCK_UNLOCKED);
115
116 __insn_barrier();
117
118 return (r);
119 }
120
121 /*
122 * Note on x86 memory ordering
123 *
124 * When releasing a lock we must ensure that no stores or loads from within
125 * the critical section are re-ordered by the CPU to occur outside of it:
126 * they must have completed and be visible to other processors once the lock
127 * has been released.
128 *
129 * NetBSD usually runs with the kernel mapped (via MTRR) in a WB (write
130 * back) memory region. In that case, memory ordering on x86 platforms
131 * looks like this:
132 *
133 * i386 All loads/stores occur in instruction sequence.
134 *
135 * i486 All loads/stores occur in instruction sequence. In
136 * Pentium exceptional circumstances, loads can be re-ordered around
137 * stores, but for the purposes of releasing a lock it does
138 * not matter. Stores may not be immediately visible to other
139 * processors as they can be buffered. However, since the
140 * stores are buffered in order the lock release will always be
141 * the last operation in the critical section that becomes
142 * visible to other CPUs.
143 *
144 * Pentium Pro The "Intel 64 and IA-32 Architectures Software Developer's
145 * onwards Manual" volume 3A (order number 248966) says that (1) "Reads
146 * can be carried out speculatively and in any order" and (2)
147 * "Reads can pass buffered stores, but the processor is
148 * self-consistent.". This would be a problem for the below,
149 * and would mandate a locked instruction cycle or load fence
150 * before releasing the simple lock.
151 *
152 * The "Intel Pentium 4 Processor Optimization" guide (order
153 * number 253668-022US) says: "Loads can be moved before stores
154 * that occurred earlier in the program if they are not
155 * predicted to load from the same linear address.". This is
156 * not a problem since the only loads that can be re-ordered
157 * take place once the lock has been released via a store.
158 *
159 * The above two documents seem to contradict each other,
160 * however with the exception of early steppings of the Pentium
161 * Pro, the second document is closer to the truth: a store
162 * will always act as a load fence for all loads that precede
163 * the store in instruction order.
164 *
165 * Again, note that stores can be buffered and will not always
166 * become immediately visible to other CPUs: they are however
167 * buffered in order.
168 *
169 * AMD64 Stores occur in order and are buffered. Loads can be
170 * reordered, however stores act as load fences, meaning that
171 * loads can not be reordered around stores.
172 */
173 static __inline void
174 __cpu_simple_unlock(__cpu_simple_lock_t *lockp)
175 {
176
177 __insn_barrier();
178 *lockp = __SIMPLELOCK_UNLOCKED;
179 }
180
181 #define SPINLOCK_SPIN_HOOK /* nothing */
182 #define SPINLOCK_BACKOFF_HOOK x86_pause()
183
184 #ifdef _KERNEL
185 void mb_read(void);
186 void mb_write(void);
187 void mb_memory(void);
188 #endif /* _KERNEL */
189
190 #endif /* _X86_LOCK_H_ */
191