LINUX内核笔记:自旋锁

目录
 
1、自旋锁作用与基本使用方法?
与其他锁一样,自旋锁也用于保护临界区,但是自旋锁主要是用于在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
 
2、在SMP和UP上的不同表现?
对于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自然只需要关闭/恢复抢占功能即可。
 
 
3、自旋锁与上下文
由于自旋锁不睡眠,既可以用于进程上下文,也可用于非进程上下文,这是它与信号量相比的一个优势。
正常来讲,如果自旋锁都是在进程上下文中使用,则建议使用spin_lock/spin_unlock。
若在中断处理例程中也要使用自旋锁,则所有争用同一个锁的地方应使用spin_lock_irqsave/spin_unlock_irqrestore。
若没有在中断而在下半部使用自旋锁,则所有急用同一个锁的地方可以使用spin_lock_bh/spin_unlock_bh,这对函数平时用得比较少。
注:自旋锁用在中断例程中,若是进程上下文中的内核代码使用spin_lock,则在临界区,可能发生中断 ,要么原子性被破坏(UP),要么造成死锁(SMP).
 
4、使用spin_lock()后为什么不能睡眠?
在UP下,正如前面所说,原子性得不到保证。
而在SMP下,则可能发生死锁:
假设有3个进程A,B,C,2个CPU称CPU0,CPU1.
CPU0上A进程获取自旋锁进入睡眠,调度了B进程,B进程将自旋; 
CPU1上调度了C进程也将自旋。
B等着A释放锁,A等着B释放CPU,自旋后的CPU不能发生调度,CPU0和CPU1将一直自旋下去,形成了死锁。
 
 
5、强调:锁什么?
使用锁的时候一定要对症下药,明确保护的是数据而不是代码,这是使用锁的正确思考方式。经常看别人代码的人应该会有所体会,针对代码加锁常常使代码难以理解,特别是复杂的程序,往往加锁没做好,引起竞争条件。
不防在使用锁的时候先思考一下自己要保护什么,然后给对应的锁取跟数据相关的名称。比如"int foo;spinlock_t foo_lock;"表示foo由foo_lock加锁;
 
6、参考
《Linux内核设计与实现》
posted @ 2014-03-27 22:33  枫叶落一地  阅读(3007)  评论(0编辑  收藏  举报