lock.h revision 1.20 1 /* $NetBSD: lock.h,v 1.20 2007/12/20 23:46:11 ad 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 static __inline int
47 __SIMPLELOCK_LOCKED_P(__cpu_simple_lock_t *__ptr)
48 {
49 return *__ptr == __SIMPLELOCK_LOCKED;
50 }
51
52 static __inline int
53 __SIMPLELOCK_UNLOCKED_P(__cpu_simple_lock_t *__ptr)
54 {
55 return *__ptr == __SIMPLELOCK_UNLOCKED;
56 }
57
58 static __inline void
59 __cpu_simple_lock_set(__cpu_simple_lock_t *__ptr)
60 {
61
62 *__ptr = __SIMPLELOCK_LOCKED;
63 }
64
65 static __inline void
66 __cpu_simple_lock_clear(__cpu_simple_lock_t *__ptr)
67 {
68
69 *__ptr = __SIMPLELOCK_UNLOCKED;
70 }
71
72 #ifdef _KERNEL
73
74 #include <machine/cpufunc.h>
75
76 void __cpu_simple_lock_init(__cpu_simple_lock_t *);
77 void __cpu_simple_lock(__cpu_simple_lock_t *);
78 int __cpu_simple_lock_try(__cpu_simple_lock_t *);
79 void __cpu_simple_unlock(__cpu_simple_lock_t *);
80
81 #define SPINLOCK_SPIN_HOOK /* nothing */
82 #define SPINLOCK_BACKOFF_HOOK x86_pause()
83
84 #else
85
86 static __inline void __cpu_simple_lock_init(__cpu_simple_lock_t *)
87 __attribute__((__unused__));
88 static __inline void __cpu_simple_lock(__cpu_simple_lock_t *)
89 __attribute__((__unused__));
90 static __inline int __cpu_simple_lock_try(__cpu_simple_lock_t *)
91 __attribute__((__unused__));
92 static __inline void __cpu_simple_unlock(__cpu_simple_lock_t *)
93 __attribute__((__unused__));
94
95 static __inline void
96 __cpu_simple_lock_init(__cpu_simple_lock_t *lockp)
97 {
98
99 *lockp = __SIMPLELOCK_UNLOCKED;
100 __insn_barrier();
101 }
102
103 static __inline int
104 __cpu_simple_lock_try(__cpu_simple_lock_t *lockp)
105 {
106 uint8_t val;
107
108 val = __SIMPLELOCK_LOCKED;
109 __asm volatile ("xchgb %0,(%2)" :
110 "=r" (val)
111 :"0" (val), "r" (lockp));
112 __insn_barrier();
113 return val == __SIMPLELOCK_UNLOCKED;
114 }
115
116 static __inline void
117 __cpu_simple_lock(__cpu_simple_lock_t *lockp)
118 {
119
120 while (!__cpu_simple_lock_try(lockp))
121 /* nothing */;
122 __insn_barrier();
123 }
124
125 /*
126 * Note on x86 memory ordering
127 *
128 * When releasing a lock we must ensure that no stores or loads from within
129 * the critical section are re-ordered by the CPU to occur outside of it:
130 * they must have completed and be visible to other processors once the lock
131 * has been released.
132 *
133 * NetBSD usually runs with the kernel mapped (via MTRR) in a WB (write
134 * back) memory region. In that case, memory ordering on x86 platforms
135 * looks like this:
136 *
137 * i386 All loads/stores occur in instruction sequence.
138 *
139 * i486 All loads/stores occur in instruction sequence. In
140 * Pentium exceptional circumstances, loads can be re-ordered around
141 * stores, but for the purposes of releasing a lock it does
142 * not matter. Stores may not be immediately visible to other
143 * processors as they can be buffered. However, since the
144 * stores are buffered in order the lock release will always be
145 * the last operation in the critical section that becomes
146 * visible to other CPUs.
147 *
148 * Pentium Pro The "Intel 64 and IA-32 Architectures Software Developer's
149 * onwards Manual" volume 3A (order number 248966) says that (1) "Reads
150 * can be carried out speculatively and in any order" and (2)
151 * "Reads can pass buffered stores, but the processor is
152 * self-consistent.". This would be a problem for the below,
153 * and would mandate a locked instruction cycle or load fence
154 * before releasing the simple lock.
155 *
156 * The "Intel Pentium 4 Processor Optimization" guide (order
157 * number 253668-022US) says: "Loads can be moved before stores
158 * that occurred earlier in the program if they are not
159 * predicted to load from the same linear address.". This is
160 * not a problem since the only loads that can be re-ordered
161 * take place once the lock has been released via a store.
162 *
163 * The above two documents seem to contradict each other,
164 * however with the exception of early steppings of the Pentium
165 * Pro, the second document is closer to the truth: a store
166 * will always act as a load fence for all loads that precede
167 * the store in instruction order.
168 *
169 * Again, note that stores can be buffered and will not always
170 * become immediately visible to other CPUs: they are however
171 * buffered in order.
172 *
173 * AMD64 Stores occur in order and are buffered. Loads can be
174 * reordered, however stores act as load fences, meaning that
175 * loads can not be reordered around stores.
176 */
177 static __inline void
178 __cpu_simple_unlock(__cpu_simple_lock_t *lockp)
179 {
180
181 __insn_barrier();
182 *lockp = __SIMPLELOCK_UNLOCKED;
183 }
184
185 #endif /* _KERNEL */
186
187 #endif /* _X86_LOCK_H_ */
188