spin_lock()--自旋锁

#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( )和宏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）

针对单处理器系统，对第一种情况，只要临时关闭系统抢占即可，我们可以使用以下方法：

[cpp]  view plain copy

1. preempt_disable();  
2. .....  
3. // 访问共享对象的代码  
4. ......  
5. preempt_enable();  

同样地，针对单处理器系统，第二种情况，只要临时关闭中断即可，我们可以使用以下方法：

[cpp]  view plain copy

1. local_irq_disable();  
2. ......  
3. // 访问共享对象的代码  
4. ......  
5. 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、并发的概念，主要是对共享资源的竞争状态，不一定是时间上的。