在smp机器上，
一个进程A（运行在cpuA上）获得了自旋锁,然后执行schedule_timeout休眠10s(只是测试),
同时另外一个进程B（运行在cpuB上）也在试图获得这个自旋锁。
我看了网上其它人的解释，说这种情况会发生死锁。 但是按照我自己的理解在进程A在cpuA睡眠期间，
进程B会在cpuB上一直忙式等待这个自旋锁，等进程A在cpuA上被唤醒后，执行完自己的操作，然后解锁。这时进程B就能够得到这个自旋锁，应该不会发生死锁啊。。。。。
另外有一个问题，我在网上看到一句话
[color=#FF0000]“另外自旋锁不允许任务睡眠(持有自旋锁的任务睡眠会造成自死锁——因为睡眠有可能造成持有锁的内核任务被重新调度，而再次申请自己已持有的锁)”
[/color]
原帖地址是http://blog.csdn.net/sandflee/archive/2009/04/10/4062596.aspx
我不明白的是，睡眠后这个拥有自旋锁的进程会接着往下执行，怎么又会去再次申请自己已持有的锁？？-----------------------------------------------------------------------------------------------------------------------------------
恰巧这两天也在看这部分,胡乱解析一通,楼主不要见怪,呵呵 .
1) 如果resource会被中断访问，a在持锁时要禁中断,否则中断再抢lock会让kernel freeze,
2) a sleep 后重新调度到，仍然在持锁的上下文中，照我看书的理解，不会重新申请锁。
当然不排除特殊情况，哈哈
----
你说的情况，在理想情况下，是不会死锁的，但是，有几个问题：
1）这个进程A睡眠以后，可能被kill掉了，这样它持有的自旋锁就永远解不开了。
2）这个进程A可能会睡眠很长时间，这个时间是不可预测的，会造成系统的停摆。
3）持有自旋锁去睡眠，是对cpu资源的极大浪费，进程A完全可以在睡眠前释放自旋锁，然后睡眠，醒来后再去获得自旋锁。
另外，你引用的
“另外自旋锁不允许任务睡眠(持有自旋锁的任务睡眠会造成自死锁——因为睡眠
有可能造成持有锁的内核任务被重新调度，而再次申请自己已持有的锁)”
我感觉是错误的。
----
你说的情况，在理想情况下，是不会死锁的，但是，有几个问题：
1）这个进程A睡眠以后，可能被kill掉了，这样它持有的自旋锁就永远解不开了。
> kill a时, 不会释放其所占资源么？ 想知道细节
2）这个进程A可能会睡眠很长时间，这个时间是不可预测的，会造成系统的停摆。
3）持有自旋锁去睡眠，是对cpu资源的极大浪费，进程A完全可以在睡眠前释放自旋锁，然后睡眠，醒来后再去获得自旋锁。
> 这个严重同意，光想想spin-lock让n个cpu干等,就知道它的威力了
另外，wheelz, 所谓系统“停摆”，是一种什么状态呢？ 有没有这方面实验过，好奇
----
> kill a时, 不会释放其所占资源么？ 想知道细节
当然不会，内核哪里知道你持有了什么锁？
> 另外，wheelz, 所谓系统“停摆”，是一种什么状态呢？ 有没有这方面实验过，好奇
没有什么特别的含义，就是说进程A睡眠了，其他想获得该锁的进程只能等待，这样不就是系统停顿了么。呵呵。
----
okay,明白了 谢谢 :-)
----
拿了spinlock之后，你还放掉CPU，这不是技术问题，是概念问题。
你的测试没有意义。
全人类没有这样写程序的。如果有可能放CPU，你要用mutex，for example
====
阅读(1369) | 评论(0) | 转发(0) |
