#include
#include
#include
自旋锁线程不能睡眠
MODULE_LICENSE("GPL");
static int __init spin_lock_init_init(void);
static void __exit spin_lock_init_exit(void);
spinlock_t lock = SPIN_LOCK_UNLOCKED;
int __init spin_lock_init_init(void)
{
printk("<0>SPIN_LOCK_UNLOCKED: %d\n",SPIN_LOCK_UNLOCKED.raw_lock.slock);
spin_lock_init( &lock ); //初始化自旋锁
printk("<0>after init, slock: %d\n",lock.raw_lock.slock);
printk("<0>\n");
spin_lock( &lock ); //第一次获取自旋锁
printk("<0>first spin_lock, slock: %d\n",lock.raw_lock.slock);
spin_unlock( &lock ); //第一次释放自旋锁
printk("<0>first spin_unlock, slock: %d\n",lock.raw_lock.slock);
printk("<0>\n");
spin_lock( &lock ); //第二次获取自旋锁
printk("<0>second spin_lock, slock: %d\n",lock.raw_lock.slock);
spin_unlock( &lock ); //第二次释放自旋锁
printk("<0>second spin_unlock, slock: %d\n",lock.raw_lock.slock);
return 0;
}
void __exit spin_lock_init_exit(void)
{
printk("<0>exit!\n");
}
module_init(spin_lock_init_init);
module_exit(spin_lock_init_exit);
首先编译模块,执行命令insmod spin_lock_init.ko 插入模块,然后执行命令dmesg –c,会出现如图8.40所示的结果:![宏:spin_lock_init <wbr>( <wbr>) 宏:spin_lock_init <wbr>( <wbr>)](http://hiphotos.baidu.com/armlinuxqt/pic/item/b417d43c8794a4c2f73434b30ef41bd5ac6e39b1.jpg)
结果分析:
测试程序中调用了宏spin_lock( )和宏spin_unlock( ),分别用来获取和释放自旋锁,关于其功能见本章中关于它们的分析。
测试程序中,首先输出宏SPIN_LOCK_UNLOCKED的信息,它所表示的自旋锁的状态为未使用。调用宏spin_lock_init( )初始化自旋锁lock,结构体raw_spinlock_t中的slock字段被置为0,即 Owner 和 Next 为 0。然后第一次执行获取和释放锁的操作,调用spin_lock( )后,slock字段为256,16进制为0x0100,即Next 域进行了加1操作;调用spin_unlock( ),slock字段为0x0101,此时Owner域也进行了加1 操作,二者相等,锁处于未使用状态。第二次获取和释放锁时,slock字段分别为0x0201和0x0202,可以看到线程是按照申请顺序依次获取排队自旋锁的。
如果一个自旋锁持有者在释放锁之前,另一个线程想要申请锁,则它会检测到锁的状态为正在被使用(因为锁未释放前Next域和Owner域不相等),从而进入忙等待。
本文不打算详细探究spin_lock的详细实现机制,只是最近对raw_spin_lock的出现比较困扰,搞不清楚什么时候用spin_lock,什么时候用raw_spin_lock,因此有了这篇文章。
/*****************************************************************************************************/
声明:本博内容均由http://blog.csdn.net/droidphone原创,转载请注明出处,谢谢!
/*****************************************************************************************************/
1. 临界区(Critical Section)
我们知道,临界区是指某个代码区间,在该区间中需要访问某些共享的数据对象,又或者是总线,硬件寄存器等,通常这段代码区间的范围要控制在尽可能小的范围内。临界区内需要对这些数据对象和硬件对象的访问进行保护,保证在退出临界区前不会被临界区外的代码对这些对象进行修改。出现以下几种情形时,我们需要使用临界区进行保护:
- (1) 在可以抢占(preemption)的系统中,两个线程同时访问同一个对象;
- (2) 线程和中断同时访问同一个对象;
- (3) 在多核系统中(SMP),可能两个CPU可能同时访问同一个对象;
2. 自旋锁(spin_lock)
针对单处理器系统,对第一种情况,只要临时关闭系统抢占即可,我们可以使用以下方法:
- preempt_disable();
- .....
-
- ......
- preempt_enable();
同样地,针对单处理器系统,第二种情况,只要临时关闭中断即可,我们可以使用以下方法:
- local_irq_disable();
- ......
-
- ......
- local_irq_enable();
那么,针对多处理器的系统,以上的方法还成立么?答案很显然:不成立。
对于第一种情况,虽然抢占被禁止了,可是另一个CPU上还有线程在运行,如果这个线程也正好要访问该共享对象,上面的代码段显然是无能为力了。
对于第二种情况,虽然本地CPU的中断被禁止了,可是另一个CPU依然可以产生中断,如果他的中断服务程序也正好要访问该共享对象,上面的代码段也一样无法对共享对象进行保护。
实际上,在linux中,上面所说的三种情况都可以用自旋锁(spin_lock)解决。基本的自旋锁函数对是:
- spin_lock(spinlock_t *lock);
- spin_unlock(spinlock_t *lock);
对于单处理器系统,在不打开调试选项时,spinlock_t实际上是一个空结构,把上面两个函数展开后,实际上就只是调用preempt_disable()和preempt_enable(),对于单处理器系统,关掉抢占后,其它线程不能被调度运行,所以并不需要做额外的工作,除非中断的到来,不过内核提供了另外的变种函数来处理中断的问题。
对于多处理器系统,spinlock_t实际上等效于内存单元中的一个整数,内核保证spin_lock系列函数对该整数进行原子操作,除了调用preempt_disable()和preempt_enable()防止线程被抢占外,还必须对spinlock_t上锁,这样,如果另一个CPU的代码要使用该临界区对象,就必须进行自旋等待。
对于中断和普通线程都要访问的对象,内核提供了另外两套变种函数:
- spin_lock_irq(spinlock_t *lock);
- spin_unlock_irq(spinlock_t *lock);
和:
- spin_lock_irqsave(lock, flags);
- spin_lock_irqrestore(lock, flags);
我们可以按以下原则使用上面的三对变种函数(宏):
- 如果只是在普通线程之间同时访问共享对象,使用spin_lock()/spin_unlock();
- 如果是在中断和普通线程之间同时访问共享对象,并且确信退出临界区后要打开中断,使用spin_lock_irq()/spin_unlock_irq();
- 如果是在中断和普通线程之间同时访问共享对象,并且退出临界区后要保持中断的状态,使用spin_lock_irqsave()/spin_unlock_irqrestore();
其实变种还不止这几个,还有read_lock_xxx/write_lock_xxx、spin_lock_bh/spin_unlock_bh、spin_trylock_xxx等等。但常用的就上面几种。
3. raw_spin_lock
在2.6.33之后的版本,内核加入了raw_spin_lock系列,使用方法和spin_lock系列一模一样,只是参数有spinlock_t变为了raw_spinlock_t。而且在内核的主线版本中,spin_lock系列只是简单地调用了raw_spin_lock系列的函数,但内核的代码却是有的地方使用spin_lock,有的地方使用raw_spin_lock。是不是很奇怪?要解答这个问题,我们要回到2004年,MontaVista Software, Inc的开发人员在邮件列表中提出来一个Real-Time Linux Kernel的模型,旨在提升Linux的实时性,之后Ingo Molnar很快在他的一个项目中实现了这个模型,并最终产生了一个Real-Time preemption的patch。
该模型允许在临界区中被抢占,而且申请临界区的操作可以导致进程休眠等待,这将导致自旋锁的机制被修改,由原来的整数原子操作变更为信号量操作。当时内核中已经有大约10000处使用了自旋锁的代码,直接修改spin_lock将会导致这个patch过于庞大,于是,他们决定只修改哪些真正不允许抢占和休眠的地方,而这些地方只有100多处,这些地方改为使用raw_spin_lock,但是,因为原来的内核中已经有raw_spin_lock这一名字空间,用于代表体系相关的原子操作的实现,于是linus本人建议:
- 把原来的raw_spin_lock改为arch_spin_lock;
- 把原来的spin_lock改为raw_spin_lock;
- 实现一个新的spin_lock;
写到这里不知大家明白了没?对于2.6.33和之后的版本,我的理解是:
- 尽可能使用spin_lock;
- 绝对不允许被抢占和休眠的地方,使用raw_spin_lock,否则使用spin_lock;
- 如果你的临界区足够小,使用raw_spin_lock;
对于没有打上Linux-RT(实时Linux)的patch的系统,spin_lock只是简单地调用raw_spin_lock,实际上他们是完全一样的,如果打上这个patch之后,spin_lock会使用信号量完成临界区的保护工作,带来的好处是同一个CPU可以有多个临界区同时工作,而原有的体系因为禁止抢占的原因,一旦进入临界区,其他临界区就无法运行,新的体系在允许使用同一个临界区的其他进程进行休眠等待,而不是强占着CPU进行自旋操作。写这篇文章的时候,内核的版本已经是3.3了,主线版本还没有合并Linux-RT的内容,说不定哪天就会合并进来,也为了你的代码可以兼容Linux-RT,最好坚持上面三个原则。
总结:
1、自旋锁不能休眠
2、自旋锁互斥的过程:
spi_lock(); 关闭调度器的课抢占性, 读自旋锁,检测,跟新自旋锁 (定义的是一个全局变量锁)
spi_lock_irq; 关闭中断(local_irq_disable),关闭调度器的课抢占性, 读自旋锁,检测,跟新自旋锁
3、并发的概念,主要是对共享资源的竞争状态,不一定是时间上的。