Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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); |
Lucas Correia Villa Real | 7ad4a5d | 2006-03-22 00:19:39 +0100 | [diff] [blame^] | 12 | rwlock_init(&xxx_rw_lock); |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 | |