aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorMuthu Kumar <muthu.lkml@gmail.com>2011-07-11 14:04:58 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2011-07-11 15:45:04 -0400
commit05801817845b308e1cf0fb8e2700b15dab79afc5 (patch)
treed2049ad193b44c387446f295ff1abe0b8647fa0e /Documentation
parente3bbfa78bab125f58b831b5f7f45b5a305091d72 (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.txt45
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);
13The above is always safe. It will disable interrupts _locally_, but the 13The above is always safe. It will disable interrupts _locally_, but the
14spinlock itself will guarantee the global lock, so it will guarantee that 14spinlock itself will guarantee the global lock, so it will guarantee that
15there is only one thread-of-control within the region(s) protected by that 15there is only one thread-of-control within the region(s) protected by that
16lock. This works well even under UP. The above sequence under UP 16lock. This works well even under UP also, so the code does _not_ need to
17essentially is just the same as doing 17worry 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
25so the code does _not_ need to worry about UP vs SMP issues: the spinlocks
26work correctly under both (and spinlocks are actually more efficient on
27architectures 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
36spinlock for most things - using more than one spinlock can make things a 26spinlock for most things - using more than one spinlock can make things a
37lot more complex and even slower and is usually worth it only for 27lot more complex and even slower and is usually worth it only for
38sequences that you _know_ need to be split up: avoid it at all cost if you 28sequences that you _know_ need to be split up: avoid it at all cost if you
39aren't sure). HOWEVER, it _does_ mean that if you have some code that does 29aren't sure).
40
41 cli();
42 .. critical section ..
43 sti();
44
45and another sequence that does
46
47 spin_lock_irqsave(flags);
48 .. critical section ..
49 spin_unlock_irqrestore(flags);
50
51then they are NOT mutually exclusive, and the critical regions can happen
52at the same time on two different CPU's. That's fine per se, but the
53critical regions had better be critical for different things (ie they
54can't stomp on each other).
55
56The above is a problem mainly if you end up mixing code - for example the
57routines in ll_rw_block() tend to use cli/sti to protect the atomicity of
58their actions, and if a driver uses spinlocks instead then you should
59think about issues like the above.
60 30
61This is really the only really hard part about spinlocks: once you start 31This is really the only really hard part about spinlocks: once you start
62using spinlocks they tend to expand to areas you might not have noticed 32using spinlocks they tend to expand to areas you might not have noticed
@@ -120,11 +90,10 @@ Lesson 3: spinlocks revisited.
120 90
121The single spin-lock primitives above are by no means the only ones. They 91The single spin-lock primitives above are by no means the only ones. They
122are the most safe ones, and the ones that work under all circumstances, 92are the most safe ones, and the ones that work under all circumstances,
123but partly _because_ they are safe they are also fairly slow. They are 93but partly _because_ they are safe they are also fairly slow. They are slower
124much faster than a generic global cli/sti pair, but slower than they'd 94than they'd need to be, because they do have to disable interrupts
125need 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 -
126single instruction on a x86, but it's an expensive one - and on other 96and on other architectures it can be worse).
127architectures it can be worse).
128 97
129If you have a case where you have to protect a data structure across 98If you have a case where you have to protect a data structure across
130several CPU's and you want to use spinlocks you can potentially use 99several CPU's and you want to use spinlocks you can potentially use