1387b1468SMauro Carvalho Chehab=============== 2387b1468SMauro Carvalho ChehabLocking lessons 3387b1468SMauro Carvalho Chehab=============== 4387b1468SMauro Carvalho Chehab 5387b1468SMauro Carvalho ChehabLesson 1: Spin locks 6387b1468SMauro Carvalho Chehab==================== 7387b1468SMauro Carvalho Chehab 8387b1468SMauro Carvalho ChehabThe most basic primitive for locking is spinlock:: 9387b1468SMauro Carvalho Chehab 10387b1468SMauro Carvalho Chehab static DEFINE_SPINLOCK(xxx_lock); 11387b1468SMauro Carvalho Chehab 12387b1468SMauro Carvalho Chehab unsigned long flags; 13387b1468SMauro Carvalho Chehab 14387b1468SMauro Carvalho Chehab spin_lock_irqsave(&xxx_lock, flags); 15387b1468SMauro Carvalho Chehab ... critical section here .. 16387b1468SMauro Carvalho Chehab spin_unlock_irqrestore(&xxx_lock, flags); 17387b1468SMauro Carvalho Chehab 18387b1468SMauro Carvalho ChehabThe above is always safe. It will disable interrupts _locally_, but the 19387b1468SMauro Carvalho Chehabspinlock itself will guarantee the global lock, so it will guarantee that 20387b1468SMauro Carvalho Chehabthere is only one thread-of-control within the region(s) protected by that 21387b1468SMauro Carvalho Chehablock. This works well even under UP also, so the code does _not_ need to 22387b1468SMauro Carvalho Chehabworry about UP vs SMP issues: the spinlocks work correctly under both. 23387b1468SMauro Carvalho Chehab 24387b1468SMauro Carvalho Chehab NOTE! Implications of spin_locks for memory are further described in: 25387b1468SMauro Carvalho Chehab 26387b1468SMauro Carvalho Chehab Documentation/memory-barriers.txt 27387b1468SMauro Carvalho Chehab 28*4bfdebd6SSeongJae Park (5) ACQUIRE operations. 29387b1468SMauro Carvalho Chehab 30*4bfdebd6SSeongJae Park (6) RELEASE operations. 31387b1468SMauro Carvalho Chehab 32387b1468SMauro Carvalho ChehabThe above is usually pretty simple (you usually need and want only one 33387b1468SMauro Carvalho Chehabspinlock for most things - using more than one spinlock can make things a 34387b1468SMauro Carvalho Chehablot more complex and even slower and is usually worth it only for 35387b1468SMauro Carvalho Chehabsequences that you **know** need to be split up: avoid it at all cost if you 36387b1468SMauro Carvalho Chehabaren't sure). 37387b1468SMauro Carvalho Chehab 38387b1468SMauro Carvalho ChehabThis is really the only really hard part about spinlocks: once you start 39387b1468SMauro Carvalho Chehabusing spinlocks they tend to expand to areas you might not have noticed 40387b1468SMauro Carvalho Chehabbefore, because you have to make sure the spinlocks correctly protect the 41387b1468SMauro Carvalho Chehabshared data structures **everywhere** they are used. The spinlocks are most 42387b1468SMauro Carvalho Chehabeasily added to places that are completely independent of other code (for 43387b1468SMauro Carvalho Chehabexample, internal driver data structures that nobody else ever touches). 44387b1468SMauro Carvalho Chehab 45387b1468SMauro Carvalho Chehab NOTE! The spin-lock is safe only when you **also** use the lock itself 46387b1468SMauro Carvalho Chehab to do locking across CPU's, which implies that EVERYTHING that 47387b1468SMauro Carvalho Chehab touches a shared variable has to agree about the spinlock they want 48387b1468SMauro Carvalho Chehab to use. 49387b1468SMauro Carvalho Chehab 50387b1468SMauro Carvalho Chehab---- 51387b1468SMauro Carvalho Chehab 52387b1468SMauro Carvalho ChehabLesson 2: reader-writer spinlocks. 53387b1468SMauro Carvalho Chehab================================== 54387b1468SMauro Carvalho Chehab 55387b1468SMauro Carvalho ChehabIf your data accesses have a very natural pattern where you usually tend 56387b1468SMauro Carvalho Chehabto mostly read from the shared variables, the reader-writer locks 57387b1468SMauro Carvalho Chehab(rw_lock) versions of the spinlocks are sometimes useful. They allow multiple 58387b1468SMauro Carvalho Chehabreaders to be in the same critical region at once, but if somebody wants 59387b1468SMauro Carvalho Chehabto change the variables it has to get an exclusive write lock. 60387b1468SMauro Carvalho Chehab 61387b1468SMauro Carvalho Chehab NOTE! reader-writer locks require more atomic memory operations than 62387b1468SMauro Carvalho Chehab simple spinlocks. Unless the reader critical section is long, you 63387b1468SMauro Carvalho Chehab are better off just using spinlocks. 64387b1468SMauro Carvalho Chehab 65387b1468SMauro Carvalho ChehabThe routines look the same as above:: 66387b1468SMauro Carvalho Chehab 67387b1468SMauro Carvalho Chehab rwlock_t xxx_lock = __RW_LOCK_UNLOCKED(xxx_lock); 68387b1468SMauro Carvalho Chehab 69387b1468SMauro Carvalho Chehab unsigned long flags; 70387b1468SMauro Carvalho Chehab 71387b1468SMauro Carvalho Chehab read_lock_irqsave(&xxx_lock, flags); 72387b1468SMauro Carvalho Chehab .. critical section that only reads the info ... 73387b1468SMauro Carvalho Chehab read_unlock_irqrestore(&xxx_lock, flags); 74387b1468SMauro Carvalho Chehab 75387b1468SMauro Carvalho Chehab write_lock_irqsave(&xxx_lock, flags); 76387b1468SMauro Carvalho Chehab .. read and write exclusive access to the info ... 77387b1468SMauro Carvalho Chehab write_unlock_irqrestore(&xxx_lock, flags); 78387b1468SMauro Carvalho Chehab 79387b1468SMauro Carvalho ChehabThe above kind of lock may be useful for complex data structures like 80387b1468SMauro Carvalho Chehablinked lists, especially searching for entries without changing the list 81387b1468SMauro Carvalho Chehabitself. The read lock allows many concurrent readers. Anything that 82387b1468SMauro Carvalho Chehab**changes** the list will have to get the write lock. 83387b1468SMauro Carvalho Chehab 84387b1468SMauro Carvalho Chehab NOTE! RCU is better for list traversal, but requires careful 85bff9e34cSMauro Carvalho Chehab attention to design detail (see Documentation/RCU/listRCU.rst). 86387b1468SMauro Carvalho Chehab 87387b1468SMauro Carvalho ChehabAlso, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_ 88387b1468SMauro Carvalho Chehabtime need to do any changes (even if you don't do it every time), you have 89387b1468SMauro Carvalho Chehabto get the write-lock at the very beginning. 90387b1468SMauro Carvalho Chehab 91387b1468SMauro Carvalho Chehab NOTE! We are working hard to remove reader-writer spinlocks in most 92387b1468SMauro Carvalho Chehab cases, so please don't add a new one without consensus. (Instead, see 93bff9e34cSMauro Carvalho Chehab Documentation/RCU/rcu.rst for complete information.) 94387b1468SMauro Carvalho Chehab 95387b1468SMauro Carvalho Chehab---- 96387b1468SMauro Carvalho Chehab 97387b1468SMauro Carvalho ChehabLesson 3: spinlocks revisited. 98387b1468SMauro Carvalho Chehab============================== 99387b1468SMauro Carvalho Chehab 100387b1468SMauro Carvalho ChehabThe single spin-lock primitives above are by no means the only ones. They 101387b1468SMauro Carvalho Chehabare the most safe ones, and the ones that work under all circumstances, 102387b1468SMauro Carvalho Chehabbut partly **because** they are safe they are also fairly slow. They are slower 103387b1468SMauro Carvalho Chehabthan they'd need to be, because they do have to disable interrupts 104387b1468SMauro Carvalho Chehab(which is just a single instruction on a x86, but it's an expensive one - 105387b1468SMauro Carvalho Chehaband on other architectures it can be worse). 106387b1468SMauro Carvalho Chehab 107387b1468SMauro Carvalho ChehabIf you have a case where you have to protect a data structure across 108387b1468SMauro Carvalho Chehabseveral CPU's and you want to use spinlocks you can potentially use 109387b1468SMauro Carvalho Chehabcheaper versions of the spinlocks. IFF you know that the spinlocks are 110387b1468SMauro Carvalho Chehabnever used in interrupt handlers, you can use the non-irq versions:: 111387b1468SMauro Carvalho Chehab 112387b1468SMauro Carvalho Chehab spin_lock(&lock); 113387b1468SMauro Carvalho Chehab ... 114387b1468SMauro Carvalho Chehab spin_unlock(&lock); 115387b1468SMauro Carvalho Chehab 116387b1468SMauro Carvalho Chehab(and the equivalent read-write versions too, of course). The spinlock will 117387b1468SMauro Carvalho Chehabguarantee the same kind of exclusive access, and it will be much faster. 118387b1468SMauro Carvalho ChehabThis is useful if you know that the data in question is only ever 119387b1468SMauro Carvalho Chehabmanipulated from a "process context", ie no interrupts involved. 120387b1468SMauro Carvalho Chehab 121387b1468SMauro Carvalho ChehabThe reasons you mustn't use these versions if you have interrupts that 122387b1468SMauro Carvalho Chehabplay with the spinlock is that you can get deadlocks:: 123387b1468SMauro Carvalho Chehab 124387b1468SMauro Carvalho Chehab spin_lock(&lock); 125387b1468SMauro Carvalho Chehab ... 126387b1468SMauro Carvalho Chehab <- interrupt comes in: 127387b1468SMauro Carvalho Chehab spin_lock(&lock); 128387b1468SMauro Carvalho Chehab 129387b1468SMauro Carvalho Chehabwhere an interrupt tries to lock an already locked variable. This is ok if 130387b1468SMauro Carvalho Chehabthe other interrupt happens on another CPU, but it is _not_ ok if the 131387b1468SMauro Carvalho Chehabinterrupt happens on the same CPU that already holds the lock, because the 132387b1468SMauro Carvalho Chehablock will obviously never be released (because the interrupt is waiting 133387b1468SMauro Carvalho Chehabfor the lock, and the lock-holder is interrupted by the interrupt and will 134387b1468SMauro Carvalho Chehabnot continue until the interrupt has been processed). 135387b1468SMauro Carvalho Chehab 136387b1468SMauro Carvalho Chehab(This is also the reason why the irq-versions of the spinlocks only need 137387b1468SMauro Carvalho Chehabto disable the _local_ interrupts - it's ok to use spinlocks in interrupts 138387b1468SMauro Carvalho Chehabon other CPU's, because an interrupt on another CPU doesn't interrupt the 139387b1468SMauro Carvalho ChehabCPU that holds the lock, so the lock-holder can continue and eventually 140387b1468SMauro Carvalho Chehabreleases the lock). 141387b1468SMauro Carvalho Chehab 142387b1468SMauro Carvalho Chehab Linus 143387b1468SMauro Carvalho Chehab 144387b1468SMauro Carvalho Chehab---- 145387b1468SMauro Carvalho Chehab 146387b1468SMauro Carvalho ChehabReference information: 147387b1468SMauro Carvalho Chehab====================== 148387b1468SMauro Carvalho Chehab 149387b1468SMauro Carvalho ChehabFor dynamic initialization, use spin_lock_init() or rwlock_init() as 150387b1468SMauro Carvalho Chehabappropriate:: 151387b1468SMauro Carvalho Chehab 152387b1468SMauro Carvalho Chehab spinlock_t xxx_lock; 153387b1468SMauro Carvalho Chehab rwlock_t xxx_rw_lock; 154387b1468SMauro Carvalho Chehab 155387b1468SMauro Carvalho Chehab static int __init xxx_init(void) 156387b1468SMauro Carvalho Chehab { 157387b1468SMauro Carvalho Chehab spin_lock_init(&xxx_lock); 158387b1468SMauro Carvalho Chehab rwlock_init(&xxx_rw_lock); 159387b1468SMauro Carvalho Chehab ... 160387b1468SMauro Carvalho Chehab } 161387b1468SMauro Carvalho Chehab 162387b1468SMauro Carvalho Chehab module_init(xxx_init); 163387b1468SMauro Carvalho Chehab 164387b1468SMauro Carvalho ChehabFor static initialization, use DEFINE_SPINLOCK() / DEFINE_RWLOCK() or 165387b1468SMauro Carvalho Chehab__SPIN_LOCK_UNLOCKED() / __RW_LOCK_UNLOCKED() as appropriate. 166