Root/
Source at commit cdde9cf73945d547acd3e96f9508c79e84ad0bf1 created 12 years 9 months ago. By Maarten ter Huurne, MMC: JZ4740: Added support for CPU frequency changing | |
---|---|
1 | Lesson 1: Spin locks |
2 | |
3 | The most basic primitive for locking is spinlock. |
4 | |
5 | static DEFINE_SPINLOCK(xxx_lock); |
6 | |
7 | unsigned long flags; |
8 | |
9 | spin_lock_irqsave(&xxx_lock, flags); |
10 | ... critical section here .. |
11 | spin_unlock_irqrestore(&xxx_lock, flags); |
12 | |
13 | The above is always safe. It will disable interrupts _locally_, but the |
14 | spinlock itself will guarantee the global lock, so it will guarantee that |
15 | there is only one thread-of-control within the region(s) protected by that |
16 | lock. This works well even under UP also, so the code does _not_ need to |
17 | worry about UP vs SMP issues: the spinlocks work correctly under both. |
18 | |
19 | NOTE! Implications of spin_locks for memory are further described in: |
20 | |
21 | Documentation/memory-barriers.txt |
22 | (5) LOCK operations. |
23 | (6) UNLOCK operations. |
24 | |
25 | The above is usually pretty simple (you usually need and want only one |
26 | spinlock for most things - using more than one spinlock can make things a |
27 | lot more complex and even slower and is usually worth it only for |
28 | sequences that you _know_ need to be split up: avoid it at all cost if you |
29 | aren't sure). |
30 | |
31 | This is really the only really hard part about spinlocks: once you start |
32 | using spinlocks they tend to expand to areas you might not have noticed |
33 | before, because you have to make sure the spinlocks correctly protect the |
34 | shared data structures _everywhere_ they are used. The spinlocks are most |
35 | easily added to places that are completely independent of other code (for |
36 | example, internal driver data structures that nobody else ever touches). |
37 | |
38 | NOTE! The spin-lock is safe only when you _also_ use the lock itself |
39 | to do locking across CPU's, which implies that EVERYTHING that |
40 | touches a shared variable has to agree about the spinlock they want |
41 | to use. |
42 | |
43 | ---- |
44 | |
45 | Lesson 2: reader-writer spinlocks. |
46 | |
47 | If your data accesses have a very natural pattern where you usually tend |
48 | to mostly read from the shared variables, the reader-writer locks |
49 | (rw_lock) versions of the spinlocks are sometimes useful. They allow multiple |
50 | readers to be in the same critical region at once, but if somebody wants |
51 | to change the variables it has to get an exclusive write lock. |
52 | |
53 | NOTE! reader-writer locks require more atomic memory operations than |
54 | simple spinlocks. Unless the reader critical section is long, you |
55 | are better off just using spinlocks. |
56 | |
57 | The routines look the same as above: |
58 | |
59 | rwlock_t xxx_lock = __RW_LOCK_UNLOCKED(xxx_lock); |
60 | |
61 | unsigned long flags; |
62 | |
63 | read_lock_irqsave(&xxx_lock, flags); |
64 | .. critical section that only reads the info ... |
65 | read_unlock_irqrestore(&xxx_lock, flags); |
66 | |
67 | write_lock_irqsave(&xxx_lock, flags); |
68 | .. read and write exclusive access to the info ... |
69 | write_unlock_irqrestore(&xxx_lock, flags); |
70 | |
71 | The above kind of lock may be useful for complex data structures like |
72 | linked lists, especially searching for entries without changing the list |
73 | itself. The read lock allows many concurrent readers. Anything that |
74 | _changes_ the list will have to get the write lock. |
75 | |
76 | NOTE! RCU is better for list traversal, but requires careful |
77 | attention to design detail (see Documentation/RCU/listRCU.txt). |
78 | |
79 | Also, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_ |
80 | time need to do any changes (even if you don't do it every time), you have |
81 | to get the write-lock at the very beginning. |
82 | |
83 | NOTE! We are working hard to remove reader-writer spinlocks in most |
84 | cases, so please don't add a new one without consensus. (Instead, see |
85 | Documentation/RCU/rcu.txt for complete information.) |
86 | |
87 | ---- |
88 | |
89 | Lesson 3: spinlocks revisited. |
90 | |
91 | The single spin-lock primitives above are by no means the only ones. They |
92 | are the most safe ones, and the ones that work under all circumstances, |
93 | but partly _because_ they are safe they are also fairly slow. They are slower |
94 | than they'd need to be, because they do have to disable interrupts |
95 | (which is just a single instruction on a x86, but it's an expensive one - |
96 | and on other architectures it can be worse). |
97 | |
98 | If you have a case where you have to protect a data structure across |
99 | several CPU's and you want to use spinlocks you can potentially use |
100 | cheaper versions of the spinlocks. IFF you know that the spinlocks are |
101 | never used in interrupt handlers, you can use the non-irq versions: |
102 | |
103 | spin_lock(&lock); |
104 | ... |
105 | spin_unlock(&lock); |
106 | |
107 | (and the equivalent read-write versions too, of course). The spinlock will |
108 | guarantee the same kind of exclusive access, and it will be much faster. |
109 | This is useful if you know that the data in question is only ever |
110 | manipulated from a "process context", ie no interrupts involved. |
111 | |
112 | The reasons you mustn't use these versions if you have interrupts that |
113 | play with the spinlock is that you can get deadlocks: |
114 | |
115 | spin_lock(&lock); |
116 | ... |
117 | <- interrupt comes in: |
118 | spin_lock(&lock); |
119 | |
120 | where an interrupt tries to lock an already locked variable. This is ok if |
121 | the other interrupt happens on another CPU, but it is _not_ ok if the |
122 | interrupt happens on the same CPU that already holds the lock, because the |
123 | lock will obviously never be released (because the interrupt is waiting |
124 | for the lock, and the lock-holder is interrupted by the interrupt and will |
125 | not continue until the interrupt has been processed). |
126 | |
127 | (This is also the reason why the irq-versions of the spinlocks only need |
128 | to disable the _local_ interrupts - it's ok to use spinlocks in interrupts |
129 | on other CPU's, because an interrupt on another CPU doesn't interrupt the |
130 | CPU that holds the lock, so the lock-holder can continue and eventually |
131 | releases the lock). |
132 | |
133 | Note that you can be clever with read-write locks and interrupts. For |
134 | example, if you know that the interrupt only ever gets a read-lock, then |
135 | you can use a non-irq version of read locks everywhere - because they |
136 | don't block on each other (and thus there is no dead-lock wrt interrupts. |
137 | But when you do the write-lock, you have to use the irq-safe version. |
138 | |
139 | For an example of being clever with rw-locks, see the "waitqueue_lock" |
140 | handling in kernel/sched.c - nothing ever _changes_ a wait-queue from |
141 | within an interrupt, they only read the queue in order to know whom to |
142 | wake up. So read-locks are safe (which is good: they are very common |
143 | indeed), while write-locks need to protect themselves against interrupts. |
144 | |
145 | Linus |
146 | |
147 | ---- |
148 | |
149 | Reference information: |
150 | |
151 | For dynamic initialization, use spin_lock_init() or rwlock_init() as |
152 | appropriate: |
153 | |
154 | spinlock_t xxx_lock; |
155 | rwlock_t xxx_rw_lock; |
156 | |
157 | static int __init xxx_init(void) |
158 | { |
159 | spin_lock_init(&xxx_lock); |
160 | rwlock_init(&xxx_rw_lock); |
161 | ... |
162 | } |
163 | |
164 | module_init(xxx_init); |
165 | |
166 | For static initialization, use DEFINE_SPINLOCK() / DEFINE_RWLOCK() or |
167 | __SPIN_LOCK_UNLOCKED() / __RW_LOCK_UNLOCKED() as appropriate. |
168 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9