1*4882a593Smuzhiyun=============== 2*4882a593SmuzhiyunLocking lessons 3*4882a593Smuzhiyun=============== 4*4882a593Smuzhiyun 5*4882a593SmuzhiyunLesson 1: Spin locks 6*4882a593Smuzhiyun==================== 7*4882a593Smuzhiyun 8*4882a593SmuzhiyunThe most basic primitive for locking is spinlock:: 9*4882a593Smuzhiyun 10*4882a593Smuzhiyun static DEFINE_SPINLOCK(xxx_lock); 11*4882a593Smuzhiyun 12*4882a593Smuzhiyun unsigned long flags; 13*4882a593Smuzhiyun 14*4882a593Smuzhiyun spin_lock_irqsave(&xxx_lock, flags); 15*4882a593Smuzhiyun ... critical section here .. 16*4882a593Smuzhiyun spin_unlock_irqrestore(&xxx_lock, flags); 17*4882a593Smuzhiyun 18*4882a593SmuzhiyunThe above is always safe. It will disable interrupts _locally_, but the 19*4882a593Smuzhiyunspinlock itself will guarantee the global lock, so it will guarantee that 20*4882a593Smuzhiyunthere is only one thread-of-control within the region(s) protected by that 21*4882a593Smuzhiyunlock. This works well even under UP also, so the code does _not_ need to 22*4882a593Smuzhiyunworry about UP vs SMP issues: the spinlocks work correctly under both. 23*4882a593Smuzhiyun 24*4882a593Smuzhiyun NOTE! Implications of spin_locks for memory are further described in: 25*4882a593Smuzhiyun 26*4882a593Smuzhiyun Documentation/memory-barriers.txt 27*4882a593Smuzhiyun 28*4882a593Smuzhiyun (5) ACQUIRE operations. 29*4882a593Smuzhiyun 30*4882a593Smuzhiyun (6) RELEASE operations. 31*4882a593Smuzhiyun 32*4882a593SmuzhiyunThe above is usually pretty simple (you usually need and want only one 33*4882a593Smuzhiyunspinlock for most things - using more than one spinlock can make things a 34*4882a593Smuzhiyunlot more complex and even slower and is usually worth it only for 35*4882a593Smuzhiyunsequences that you **know** need to be split up: avoid it at all cost if you 36*4882a593Smuzhiyunaren't sure). 37*4882a593Smuzhiyun 38*4882a593SmuzhiyunThis is really the only really hard part about spinlocks: once you start 39*4882a593Smuzhiyunusing spinlocks they tend to expand to areas you might not have noticed 40*4882a593Smuzhiyunbefore, because you have to make sure the spinlocks correctly protect the 41*4882a593Smuzhiyunshared data structures **everywhere** they are used. The spinlocks are most 42*4882a593Smuzhiyuneasily added to places that are completely independent of other code (for 43*4882a593Smuzhiyunexample, internal driver data structures that nobody else ever touches). 44*4882a593Smuzhiyun 45*4882a593Smuzhiyun NOTE! The spin-lock is safe only when you **also** use the lock itself 46*4882a593Smuzhiyun to do locking across CPU's, which implies that EVERYTHING that 47*4882a593Smuzhiyun touches a shared variable has to agree about the spinlock they want 48*4882a593Smuzhiyun to use. 49*4882a593Smuzhiyun 50*4882a593Smuzhiyun---- 51*4882a593Smuzhiyun 52*4882a593SmuzhiyunLesson 2: reader-writer spinlocks. 53*4882a593Smuzhiyun================================== 54*4882a593Smuzhiyun 55*4882a593SmuzhiyunIf your data accesses have a very natural pattern where you usually tend 56*4882a593Smuzhiyunto mostly read from the shared variables, the reader-writer locks 57*4882a593Smuzhiyun(rw_lock) versions of the spinlocks are sometimes useful. They allow multiple 58*4882a593Smuzhiyunreaders to be in the same critical region at once, but if somebody wants 59*4882a593Smuzhiyunto change the variables it has to get an exclusive write lock. 60*4882a593Smuzhiyun 61*4882a593Smuzhiyun NOTE! reader-writer locks require more atomic memory operations than 62*4882a593Smuzhiyun simple spinlocks. Unless the reader critical section is long, you 63*4882a593Smuzhiyun are better off just using spinlocks. 64*4882a593Smuzhiyun 65*4882a593SmuzhiyunThe routines look the same as above:: 66*4882a593Smuzhiyun 67*4882a593Smuzhiyun rwlock_t xxx_lock = __RW_LOCK_UNLOCKED(xxx_lock); 68*4882a593Smuzhiyun 69*4882a593Smuzhiyun unsigned long flags; 70*4882a593Smuzhiyun 71*4882a593Smuzhiyun read_lock_irqsave(&xxx_lock, flags); 72*4882a593Smuzhiyun .. critical section that only reads the info ... 73*4882a593Smuzhiyun read_unlock_irqrestore(&xxx_lock, flags); 74*4882a593Smuzhiyun 75*4882a593Smuzhiyun write_lock_irqsave(&xxx_lock, flags); 76*4882a593Smuzhiyun .. read and write exclusive access to the info ... 77*4882a593Smuzhiyun write_unlock_irqrestore(&xxx_lock, flags); 78*4882a593Smuzhiyun 79*4882a593SmuzhiyunThe above kind of lock may be useful for complex data structures like 80*4882a593Smuzhiyunlinked lists, especially searching for entries without changing the list 81*4882a593Smuzhiyunitself. The read lock allows many concurrent readers. Anything that 82*4882a593Smuzhiyun**changes** the list will have to get the write lock. 83*4882a593Smuzhiyun 84*4882a593Smuzhiyun NOTE! RCU is better for list traversal, but requires careful 85*4882a593Smuzhiyun attention to design detail (see Documentation/RCU/listRCU.rst). 86*4882a593Smuzhiyun 87*4882a593SmuzhiyunAlso, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_ 88*4882a593Smuzhiyuntime need to do any changes (even if you don't do it every time), you have 89*4882a593Smuzhiyunto get the write-lock at the very beginning. 90*4882a593Smuzhiyun 91*4882a593Smuzhiyun NOTE! We are working hard to remove reader-writer spinlocks in most 92*4882a593Smuzhiyun cases, so please don't add a new one without consensus. (Instead, see 93*4882a593Smuzhiyun Documentation/RCU/rcu.rst for complete information.) 94*4882a593Smuzhiyun 95*4882a593Smuzhiyun---- 96*4882a593Smuzhiyun 97*4882a593SmuzhiyunLesson 3: spinlocks revisited. 98*4882a593Smuzhiyun============================== 99*4882a593Smuzhiyun 100*4882a593SmuzhiyunThe single spin-lock primitives above are by no means the only ones. They 101*4882a593Smuzhiyunare the most safe ones, and the ones that work under all circumstances, 102*4882a593Smuzhiyunbut partly **because** they are safe they are also fairly slow. They are slower 103*4882a593Smuzhiyunthan they'd need to be, because they do have to disable interrupts 104*4882a593Smuzhiyun(which is just a single instruction on a x86, but it's an expensive one - 105*4882a593Smuzhiyunand on other architectures it can be worse). 106*4882a593Smuzhiyun 107*4882a593SmuzhiyunIf you have a case where you have to protect a data structure across 108*4882a593Smuzhiyunseveral CPU's and you want to use spinlocks you can potentially use 109*4882a593Smuzhiyuncheaper versions of the spinlocks. IFF you know that the spinlocks are 110*4882a593Smuzhiyunnever used in interrupt handlers, you can use the non-irq versions:: 111*4882a593Smuzhiyun 112*4882a593Smuzhiyun spin_lock(&lock); 113*4882a593Smuzhiyun ... 114*4882a593Smuzhiyun spin_unlock(&lock); 115*4882a593Smuzhiyun 116*4882a593Smuzhiyun(and the equivalent read-write versions too, of course). The spinlock will 117*4882a593Smuzhiyunguarantee the same kind of exclusive access, and it will be much faster. 118*4882a593SmuzhiyunThis is useful if you know that the data in question is only ever 119*4882a593Smuzhiyunmanipulated from a "process context", ie no interrupts involved. 120*4882a593Smuzhiyun 121*4882a593SmuzhiyunThe reasons you mustn't use these versions if you have interrupts that 122*4882a593Smuzhiyunplay with the spinlock is that you can get deadlocks:: 123*4882a593Smuzhiyun 124*4882a593Smuzhiyun spin_lock(&lock); 125*4882a593Smuzhiyun ... 126*4882a593Smuzhiyun <- interrupt comes in: 127*4882a593Smuzhiyun spin_lock(&lock); 128*4882a593Smuzhiyun 129*4882a593Smuzhiyunwhere an interrupt tries to lock an already locked variable. This is ok if 130*4882a593Smuzhiyunthe other interrupt happens on another CPU, but it is _not_ ok if the 131*4882a593Smuzhiyuninterrupt happens on the same CPU that already holds the lock, because the 132*4882a593Smuzhiyunlock will obviously never be released (because the interrupt is waiting 133*4882a593Smuzhiyunfor the lock, and the lock-holder is interrupted by the interrupt and will 134*4882a593Smuzhiyunnot continue until the interrupt has been processed). 135*4882a593Smuzhiyun 136*4882a593Smuzhiyun(This is also the reason why the irq-versions of the spinlocks only need 137*4882a593Smuzhiyunto disable the _local_ interrupts - it's ok to use spinlocks in interrupts 138*4882a593Smuzhiyunon other CPU's, because an interrupt on another CPU doesn't interrupt the 139*4882a593SmuzhiyunCPU that holds the lock, so the lock-holder can continue and eventually 140*4882a593Smuzhiyunreleases the lock). 141*4882a593Smuzhiyun 142*4882a593Smuzhiyun Linus 143*4882a593Smuzhiyun 144*4882a593Smuzhiyun---- 145*4882a593Smuzhiyun 146*4882a593SmuzhiyunReference information: 147*4882a593Smuzhiyun====================== 148*4882a593Smuzhiyun 149*4882a593SmuzhiyunFor dynamic initialization, use spin_lock_init() or rwlock_init() as 150*4882a593Smuzhiyunappropriate:: 151*4882a593Smuzhiyun 152*4882a593Smuzhiyun spinlock_t xxx_lock; 153*4882a593Smuzhiyun rwlock_t xxx_rw_lock; 154*4882a593Smuzhiyun 155*4882a593Smuzhiyun static int __init xxx_init(void) 156*4882a593Smuzhiyun { 157*4882a593Smuzhiyun spin_lock_init(&xxx_lock); 158*4882a593Smuzhiyun rwlock_init(&xxx_rw_lock); 159*4882a593Smuzhiyun ... 160*4882a593Smuzhiyun } 161*4882a593Smuzhiyun 162*4882a593Smuzhiyun module_init(xxx_init); 163*4882a593Smuzhiyun 164*4882a593SmuzhiyunFor static initialization, use DEFINE_SPINLOCK() / DEFINE_RWLOCK() or 165*4882a593Smuzhiyun__SPIN_LOCK_UNLOCKED() / __RW_LOCK_UNLOCKED() as appropriate. 166