目录
与其他锁一样,自旋锁也用于保护临界区,但是自旋锁主要是用于在SMP上保护临界区。在SMP上,自旋锁最多只能被一个可执行线程持有,如果一个线程尝试获得一个被争用的自旋锁,该线程将一直旋转(while循环)直到锁可用;如果锁未被争用,请求锁的执行线程将立刻争用它,并继续执行。
LINUX下自旋锁的基本使用方法:
声明锁:
spinlock_t lock;
初始化:
lock = SPIN_LOCK_UNLOCKED;
或者
spin_lock_init(&lock);
加锁有4个接口,3个会阻塞,1个不阻塞
spin_lock(&lock);//获取自旋锁 spin_lock_irq(&lock);//关中断,获取自旋锁,不建议使用 spin_lock_irqsave(&lock, flags);//关中断,保存中断状态,获取自旋锁 spin_trylock(&lock);//与spin_lock一样,但是获取不到的时候不阻塞,返回非0
对应的解锁接口有3个
spin_unlock(&lock);//spin_lock和spin_trylock都用该接口解锁 spin_unlock_irq(&lock);//不建议使用 spin_unlock_irqrestore(&lock, flags);
另外还提供了一个获取锁状态的接口:
spin_is_locked(&lock);//如果指定的锁被获取,返回非0,否则,返回0
对于SMP,自旋锁将在禁止抢占后,while循环自旋直到锁可用;
对于UP,自旋锁的行为有点不一样,具体表现为:
- 内核不支持抢占,则spin_lock是个空函数,spin_unlock也是空函数;
- 内核支持抢占,则spin_lock关抢占,spin_unlock开抢占。
要分析SMP和UP的区别,还得先理解UP下内核支持抢占与否的区分。
在不支持抢占的时候,内核调度时机为:
- 内核代码一直要执行到完成(返回用户空间);
- 阻塞或主动调用schedule();
支持内核抢占的内核,则在以下情况会发生抢占:
- 从中断处理程序回到内核空间且内核具有抢占性时;
- 当内核代码再一次具有可抢占性时;(如时钟中断,发现进程时间片已经用完,则发生进程抢占)
- 内核显式调用schedule();
- 内核中的任务阻塞(同样导致schedule());
而对于支持抢占的内核, spin_lock/spin_unlock自然只需要关闭/恢复抢占功能即可。
由于自旋锁不睡眠,既可以用于进程上下文,也可用于非进程上下文,这是它与信号量相比的一个优势。
正常来讲,如果自旋锁都是在进程上下文中使用,则建议使用spin_lock/spin_unlock。
若在中断处理例程中也要使用自旋锁,则所有争用同一个锁的地方应使用spin_lock_irqsave/spin_unlock_irqrestore。
若没有在中断而在下半部使用自旋锁,则所有急用同一个锁的地方可以使用spin_lock_bh/spin_unlock_bh,这对函数平时用得比较少。
注:自旋锁用在中断例程中,若是进程上下文中的内核代码使用spin_lock,则在临界区,可能发生中断 ,要么原子性被破坏(UP),要么造成死锁(SMP).
在UP下,正如前面所说,原子性得不到保证。
而在SMP下,则可能发生死锁:
假设有3个进程A,B,C,2个CPU称CPU0,CPU1.
CPU0上A进程获取自旋锁进入睡眠,调度了B进程,B进程将自旋;
CPU1上调度了C进程也将自旋。
B等着A释放锁,A等着B释放CPU,自旋后的CPU不能发生调度,CPU0和CPU1将一直自旋下去,形成了死锁。
使用锁的时候一定要对症下药,明确保护的是数据而不是代码,这是使用锁的正确思考方式。经常看别人代码的人应该会有所体会,针对代码加锁常常使代码难以理解,特别是复杂的程序,往往加锁没做好,引起竞争条件。
不防在使用锁的时候先思考一下自己要保护什么,然后给对应的锁取跟数据相关的名称。比如"int foo;spinlock_t foo_lock;"表示foo由foo_lock加锁;
《Linux内核设计与实现》