单cpu抢占模式下自旋锁为什么会要禁止抢占？

new_learner

原帖由 xiegang112 于 2009-2-7 20:01 发表
单cpu抢占模式下，spin_lock定义是禁止抢占。在网上查了些文章，大概意思是说如果如果不禁止抢占，会造成死锁。但是我觉得理论上应该不会造成死锁。一个进程获得了资源的自旋锁，在访问资源期间，被其他进程抢占。新的进程为了访问该资源，去获得该锁。此时形成了一个竞态条件。如果没有外界干预，就是死锁现象。但是，因为存在中断，他可能打断新进程的忙等，老进程有机会获得cpu，完成对资源的访问并释放锁，从而避免死锁。
所以，我觉得单cpu spin_lock中禁止抢断并不会造成死锁，而是有可能引起性能的下降。不知道理解是否正确？

谢谢

我觉得你这句话：
"所以，我觉得单cpu spin_lock中禁止抢断并不会造成死锁，而是有可能引起性能的下降。"
是对的！
只是kernel不可能这样去冒险降低系统性能，所以为了万无一失，有这样一对函数：

1. 
   
2. spin_lock_irqsave(lock, flags);
   
3. spin_unlock_irqrestore(lock, flags) ;
   

复制代码

这样把中断也屏蔽掉了，就不会发生"引起性能的下降".

new_learner

原帖由 dreamice 于 2009-2-8 15:59 发表


你说的是对的。由于2.6内核版本加入了抢占的特性，但我们可以配置为抢占和非抢占模式。
在单处理器2.6版本的非抢占模式下，spin_lock被编译为一条空语句，什么都不干；
在单处理器2.6版本的抢占模式下，s ...

好像是LKD2上的总结

zylthinking

原帖由 xiegang112 于 2009-2-7 20:01 发表
单cpu抢占模式下，spin_lock定义是禁止抢占。在网上查了些文章，大概意思是说如果如果不禁止抢占，会造成死锁。但是我觉得理论上应该不会造成死锁。一个进程获得了资源的自旋锁，在访问资源期间，被其他进程抢占 ...

如果在UP 可抢占内核下自旋锁实现和 SMP 下实现相同， 会不会导致死锁呢？

自然中断是允许的， 从中断返回也可能重新schedule, 从而导致正在自旋的任务被切换掉， 似乎引不起死锁， 最多性能降低。
除非自旋的任务在自旋时不耗费时间片， 那么因为当前任务时间片剩余， schedule 不会被调用， 任何中断最终还是会返回正在自旋的任务， 导致无限自旋下去。

有谁能解释一下吗

Jacob_linux

不是分抢占与非抢占吗回复 3# Godbach