Documentation/spinlocks.txt: Remove reference to sti()/cli()

+7 -38

1 changed file

expand all

Documentation

spinlocks.txt

+7 -38

Documentation/spinlocks.txt

··· 13 13 The above is always safe. It will disable interrupts _locally_, but the 14 14 spinlock itself will guarantee the global lock, so it will guarantee that 15 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 17 - essentially is just the same as doing 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). 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. 28 18 29 19 NOTE! Implications of spin_locks for memory are further described in: 30 20 ··· 26 36 spinlock for most things - using more than one spinlock can make things a 27 37 lot more complex and even slower and is usually worth it only for 28 38 sequences that you _know_ need to be split up: avoid it at all cost if you 29 - aren't sure). HOWEVER, it _does_ mean that if you have some code that does 30 - 31 - cli(); 32 - .. critical section .. 33 - sti(); 34 - 35 - and another sequence that does 36 - 37 - spin_lock_irqsave(flags); 38 - .. critical section .. 39 - spin_unlock_irqrestore(flags); 40 - 41 - then they are NOT mutually exclusive, and the critical regions can happen 42 - at the same time on two different CPU's. That's fine per se, but the 43 - critical regions had better be critical for different things (ie they 44 - can't stomp on each other). 45 - 46 - The above is a problem mainly if you end up mixing code - for example the 47 - routines in ll_rw_block() tend to use cli/sti to protect the atomicity of 48 - their actions, and if a driver uses spinlocks instead then you should 49 - think about issues like the above. 39 + aren't sure). 50 40 51 41 This is really the only really hard part about spinlocks: once you start 52 42 using spinlocks they tend to expand to areas you might not have noticed ··· 90 120 91 121 The single spin-lock primitives above are by no means the only ones. They 92 122 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 94 - much faster than a generic global cli/sti pair, but slower than they'd 95 - need to be, because they do have to disable interrupts (which is just a 96 - single instruction on a x86, but it's an expensive one - and on other 97 - architectures it can be worse). 123 + but partly _because_ they are safe they are also fairly slow. They are slower 124 + than they'd need to be, because they do have to disable interrupts 125 + (which is just a single instruction on a x86, but it's an expensive one - 126 + and on other architectures it can be worse). 98 127 99 128 If you have a case where you have to protect a data structure across 100 129 several CPU's and you want to use spinlocks you can potentially use

Configure Feed

Configure Feed