Contents of /alx-src/tags/kernel26-2.6.12-alx-r9/Documentation/spinlocks.txt
Parent Directory | Revision Log
Revision 630 -
(show annotations)
(download)
Wed Mar 4 11:03:09 2009 UTC (15 years, 6 months ago) by niro
File MIME type: text/plain
File size: 8611 byte(s)
Wed Mar 4 11:03:09 2009 UTC (15 years, 6 months ago) by niro
File MIME type: text/plain
File size: 8611 byte(s)
Tag kernel26-2.6.12-alx-r9
1 | UPDATE March 21 2005 Amit Gud <gud@eth.net> |
2 | |
3 | Macros SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED are deprecated and will be |
4 | removed soon. So for any new code dynamic initialization should be used: |
5 | |
6 | spinlock_t xxx_lock; |
7 | rwlock_t xxx_rw_lock; |
8 | |
9 | static int __init xxx_init(void) |
10 | { |
11 | spin_lock_init(&xxx_lock); |
12 | rw_lock_init(&xxx_rw_lock); |
13 | ... |
14 | } |
15 | |
16 | module_init(xxx_init); |
17 | |
18 | Reasons for deprecation |
19 | - it hurts automatic lock validators |
20 | - it becomes intrusive for the realtime preemption patches |
21 | |
22 | Following discussion is still valid, however, with the dynamic initialization |
23 | of spinlocks instead of static. |
24 | |
25 | ----------------------- |
26 | |
27 | On Fri, 2 Jan 1998, Doug Ledford wrote: |
28 | > |
29 | > I'm working on making the aic7xxx driver more SMP friendly (as well as |
30 | > importing the latest FreeBSD sequencer code to have 7895 support) and wanted |
31 | > to get some info from you. The goal here is to make the various routines |
32 | > SMP safe as well as UP safe during interrupts and other manipulating |
33 | > routines. So far, I've added a spin_lock variable to things like my queue |
34 | > structs. Now, from what I recall, there are some spin lock functions I can |
35 | > use to lock these spin locks from other use as opposed to a (nasty) |
36 | > save_flags(); cli(); stuff; restore_flags(); construct. Where do I find |
37 | > these routines and go about making use of them? Do they only lock on a |
38 | > per-processor basis or can they also lock say an interrupt routine from |
39 | > mucking with a queue if the queue routine was manipulating it when the |
40 | > interrupt occurred, or should I still use a cli(); based construct on that |
41 | > one? |
42 | |
43 | See <asm/spinlock.h>. The basic version is: |
44 | |
45 | spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED; |
46 | |
47 | |
48 | unsigned long flags; |
49 | |
50 | spin_lock_irqsave(&xxx_lock, flags); |
51 | ... critical section here .. |
52 | spin_unlock_irqrestore(&xxx_lock, flags); |
53 | |
54 | and the above is always safe. It will disable interrupts _locally_, but the |
55 | spinlock itself will guarantee the global lock, so it will guarantee that |
56 | there is only one thread-of-control within the region(s) protected by that |
57 | lock. |
58 | |
59 | Note that it works well even under UP - the above sequence under UP |
60 | essentially is just the same as doing a |
61 | |
62 | unsigned long flags; |
63 | |
64 | save_flags(flags); cli(); |
65 | ... critical section ... |
66 | restore_flags(flags); |
67 | |
68 | so the code does _not_ need to worry about UP vs SMP issues: the spinlocks |
69 | work correctly under both (and spinlocks are actually more efficient on |
70 | architectures that allow doing the "save_flags + cli" in one go because I |
71 | don't export that interface normally). |
72 | |
73 | NOTE NOTE NOTE! The reason the spinlock is so much faster than a global |
74 | interrupt lock under SMP is exactly because it disables interrupts only on |
75 | the local CPU. The spin-lock is safe only when you _also_ use the lock |
76 | itself to do locking across CPU's, which implies that EVERYTHING that |
77 | touches a shared variable has to agree about the spinlock they want to |
78 | use. |
79 | |
80 | The above is usually pretty simple (you usually need and want only one |
81 | spinlock for most things - using more than one spinlock can make things a |
82 | lot more complex and even slower and is usually worth it only for |
83 | sequences that you _know_ need to be split up: avoid it at all cost if you |
84 | aren't sure). HOWEVER, it _does_ mean that if you have some code that does |
85 | |
86 | cli(); |
87 | .. critical section .. |
88 | sti(); |
89 | |
90 | and another sequence that does |
91 | |
92 | spin_lock_irqsave(flags); |
93 | .. critical section .. |
94 | spin_unlock_irqrestore(flags); |
95 | |
96 | then they are NOT mutually exclusive, and the critical regions can happen |
97 | at the same time on two different CPU's. That's fine per se, but the |
98 | critical regions had better be critical for different things (ie they |
99 | can't stomp on each other). |
100 | |
101 | The above is a problem mainly if you end up mixing code - for example the |
102 | routines in ll_rw_block() tend to use cli/sti to protect the atomicity of |
103 | their actions, and if a driver uses spinlocks instead then you should |
104 | think about issues like the above.. |
105 | |
106 | This is really the only really hard part about spinlocks: once you start |
107 | using spinlocks they tend to expand to areas you might not have noticed |
108 | before, because you have to make sure the spinlocks correctly protect the |
109 | shared data structures _everywhere_ they are used. The spinlocks are most |
110 | easily added to places that are completely independent of other code (ie |
111 | internal driver data structures that nobody else ever touches, for |
112 | example). |
113 | |
114 | ---- |
115 | |
116 | Lesson 2: reader-writer spinlocks. |
117 | |
118 | If your data accesses have a very natural pattern where you usually tend |
119 | to mostly read from the shared variables, the reader-writer locks |
120 | (rw_lock) versions of the spinlocks are often nicer. They allow multiple |
121 | readers to be in the same critical region at once, but if somebody wants |
122 | to change the variables it has to get an exclusive write lock. The |
123 | routines look the same as above: |
124 | |
125 | rwlock_t xxx_lock = RW_LOCK_UNLOCKED; |
126 | |
127 | |
128 | unsigned long flags; |
129 | |
130 | read_lock_irqsave(&xxx_lock, flags); |
131 | .. critical section that only reads the info ... |
132 | read_unlock_irqrestore(&xxx_lock, flags); |
133 | |
134 | write_lock_irqsave(&xxx_lock, flags); |
135 | .. read and write exclusive access to the info ... |
136 | write_unlock_irqrestore(&xxx_lock, flags); |
137 | |
138 | The above kind of lock is useful for complex data structures like linked |
139 | lists etc, especially when you know that most of the work is to just |
140 | traverse the list searching for entries without changing the list itself, |
141 | for example. Then you can use the read lock for that kind of list |
142 | traversal, which allows many concurrent readers. Anything that _changes_ |
143 | the list will have to get the write lock. |
144 | |
145 | Note: you cannot "upgrade" a read-lock to a write-lock, so if you at _any_ |
146 | time need to do any changes (even if you don't do it every time), you have |
147 | to get the write-lock at the very beginning. I could fairly easily add a |
148 | primitive to create a "upgradeable" read-lock, but it hasn't been an issue |
149 | yet. Tell me if you'd want one. |
150 | |
151 | ---- |
152 | |
153 | Lesson 3: spinlocks revisited. |
154 | |
155 | The single spin-lock primitives above are by no means the only ones. They |
156 | are the most safe ones, and the ones that work under all circumstances, |
157 | but partly _because_ they are safe they are also fairly slow. They are |
158 | much faster than a generic global cli/sti pair, but slower than they'd |
159 | need to be, because they do have to disable interrupts (which is just a |
160 | single instruction on a x86, but it's an expensive one - and on other |
161 | architectures it can be worse). |
162 | |
163 | If you have a case where you have to protect a data structure across |
164 | several CPU's and you want to use spinlocks you can potentially use |
165 | cheaper versions of the spinlocks. IFF you know that the spinlocks are |
166 | never used in interrupt handlers, you can use the non-irq versions: |
167 | |
168 | spin_lock(&lock); |
169 | ... |
170 | spin_unlock(&lock); |
171 | |
172 | (and the equivalent read-write versions too, of course). The spinlock will |
173 | guarantee the same kind of exclusive access, and it will be much faster. |
174 | This is useful if you know that the data in question is only ever |
175 | manipulated from a "process context", ie no interrupts involved. |
176 | |
177 | The reasons you mustn't use these versions if you have interrupts that |
178 | play with the spinlock is that you can get deadlocks: |
179 | |
180 | spin_lock(&lock); |
181 | ... |
182 | <- interrupt comes in: |
183 | spin_lock(&lock); |
184 | |
185 | where an interrupt tries to lock an already locked variable. This is ok if |
186 | the other interrupt happens on another CPU, but it is _not_ ok if the |
187 | interrupt happens on the same CPU that already holds the lock, because the |
188 | lock will obviously never be released (because the interrupt is waiting |
189 | for the lock, and the lock-holder is interrupted by the interrupt and will |
190 | not continue until the interrupt has been processed). |
191 | |
192 | (This is also the reason why the irq-versions of the spinlocks only need |
193 | to disable the _local_ interrupts - it's ok to use spinlocks in interrupts |
194 | on other CPU's, because an interrupt on another CPU doesn't interrupt the |
195 | CPU that holds the lock, so the lock-holder can continue and eventually |
196 | releases the lock). |
197 | |
198 | Note that you can be clever with read-write locks and interrupts. For |
199 | example, if you know that the interrupt only ever gets a read-lock, then |
200 | you can use a non-irq version of read locks everywhere - because they |
201 | don't block on each other (and thus there is no dead-lock wrt interrupts. |
202 | But when you do the write-lock, you have to use the irq-safe version. |
203 | |
204 | For an example of being clever with rw-locks, see the "waitqueue_lock" |
205 | handling in kernel/sched.c - nothing ever _changes_ a wait-queue from |
206 | within an interrupt, they only read the queue in order to know whom to |
207 | wake up. So read-locks are safe (which is good: they are very common |
208 | indeed), while write-locks need to protect themselves against interrupts. |
209 | |
210 | Linus |
211 | |
212 |