diff options
author | Muthu Kumar <muthu.lkml@gmail.com> | 2011-07-11 14:04:58 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2011-07-11 15:45:04 -0400 |
commit | 05801817845b308e1cf0fb8e2700b15dab79afc5 (patch) | |
tree | d2049ad193b44c387446f295ff1abe0b8647fa0e /Documentation | |
parent | e3bbfa78bab125f58b831b5f7f45b5a305091d72 (diff) |
Documentation/spinlocks.txt: Remove reference to sti()/cli()
Since we removed sti()/cli() and related, how about removing it from
Documentation/spinlocks.txt?
Signed-off-by: Muthukumar R <muthur@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/spinlocks.txt | 45 |
1 files changed, 7 insertions, 38 deletions
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt index 2e3c64b1a6a5..9dbe885ecd8d 100644 --- a/Documentation/spinlocks.txt +++ b/Documentation/spinlocks.txt | |||
@@ -13,18 +13,8 @@ static DEFINE_SPINLOCK(xxx_lock); | |||
13 | The above is always safe. It will disable interrupts _locally_, but the | 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 | 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 | 15 | there is only one thread-of-control within the region(s) protected by that |
16 | lock. This works well even under UP. The above sequence under UP | 16 | lock. This works well even under UP also, so the code does _not_ need to |
17 | essentially is just the same as doing | 17 | worry about UP vs SMP issues: the spinlocks work correctly under both. |
18 | |||
19 | unsigned long flags; | ||
20 | |||
21 | save_flags(flags); cli(); | ||
22 | ... critical section ... | ||
23 | restore_flags(flags); | ||
24 | |||
25 | so the code does _not_ need to worry about UP vs SMP issues: the spinlocks | ||
26 | work correctly under both (and spinlocks are actually more efficient on | ||
27 | architectures that allow doing the "save_flags + cli" in one operation). | ||
28 | 18 | ||
29 | NOTE! Implications of spin_locks for memory are further described in: | 19 | NOTE! Implications of spin_locks for memory are further described in: |
30 | 20 | ||
@@ -36,27 +26,7 @@ The above is usually pretty simple (you usually need and want only one | |||
36 | spinlock for most things - using more than one spinlock can make things a | 26 | spinlock for most things - using more than one spinlock can make things a |
37 | lot more complex and even slower and is usually worth it only for | 27 | lot more complex and even slower and is usually worth it only for |
38 | sequences that you _know_ need to be split up: avoid it at all cost if you | 28 | sequences that you _know_ need to be split up: avoid it at all cost if you |
39 | aren't sure). HOWEVER, it _does_ mean that if you have some code that does | 29 | aren't sure). |
40 | |||
41 | cli(); | ||
42 | .. critical section .. | ||
43 | sti(); | ||
44 | |||
45 | and another sequence that does | ||
46 | |||
47 | spin_lock_irqsave(flags); | ||
48 | .. critical section .. | ||
49 | spin_unlock_irqrestore(flags); | ||
50 | |||
51 | then they are NOT mutually exclusive, and the critical regions can happen | ||
52 | at the same time on two different CPU's. That's fine per se, but the | ||
53 | critical regions had better be critical for different things (ie they | ||
54 | can't stomp on each other). | ||
55 | |||
56 | The above is a problem mainly if you end up mixing code - for example the | ||
57 | routines in ll_rw_block() tend to use cli/sti to protect the atomicity of | ||
58 | their actions, and if a driver uses spinlocks instead then you should | ||
59 | think about issues like the above. | ||
60 | 30 | ||
61 | This is really the only really hard part about spinlocks: once you start | 31 | This is really the only really hard part about spinlocks: once you start |
62 | using spinlocks they tend to expand to areas you might not have noticed | 32 | using spinlocks they tend to expand to areas you might not have noticed |
@@ -120,11 +90,10 @@ Lesson 3: spinlocks revisited. | |||
120 | 90 | ||
121 | The single spin-lock primitives above are by no means the only ones. They | 91 | The single spin-lock primitives above are by no means the only ones. They |
122 | are the most safe ones, and the ones that work under all circumstances, | 92 | are the most safe ones, and the ones that work under all circumstances, |
123 | but partly _because_ they are safe they are also fairly slow. They are | 93 | but partly _because_ they are safe they are also fairly slow. They are slower |
124 | much faster than a generic global cli/sti pair, but slower than they'd | 94 | than they'd need to be, because they do have to disable interrupts |
125 | need to be, because they do have to disable interrupts (which is just a | 95 | (which is just a single instruction on a x86, but it's an expensive one - |
126 | single instruction on a x86, but it's an expensive one - and on other | 96 | and on other architectures it can be worse). |
127 | architectures it can be worse). | ||
128 | 97 | ||
129 | If you have a case where you have to protect a data structure across | 98 | If you have a case where you have to protect a data structure across |
130 | several CPU's and you want to use spinlocks you can potentially use | 99 | several CPU's and you want to use spinlocks you can potentially use |