spin_lock死锁问题

h123e

以下这段代码竞争的话，就会产生死锁了。因为在释放A锁之前没有释放掉B锁。 当第一个进程在4释放掉A锁后，另一个进程可能执行1，获取到这个A锁。
然后这时第一个进程获取了B锁，执行到6时等待A锁，而另一个进行获取了A锁，在2等待B锁。这样就死锁了。

如果在释放A锁之前释放掉B锁的话，也就是在3处加上spin_unlock(&B)，这样就不会有问题了。所以释放锁还是要按顺序释放。
不过个人认为如果没有6，7步的话，应该释放锁的顺序没有什么影响。

1：spin_lock(&A);
2：spin_lock(&B);
3：place1
4：spin_unlock(&A);
5：some codes need not lock A
6：spin_lock(&A);
  ....
7：spin_unlock(&A);
8：spin_unlock(&B);

sygspjlsj

回复 11# h123e
感觉你这个分析有问题哦，整个锁的顺序是1、2.。。。。7、8，你怎么又在中间讨论起3、4了，如果单纯的讨论1278的话，释放锁得顺序是无所谓的


   

sygspjlsj

回复 7# amarant
接着你的分析：如果先释放B，则第一个进程仍然占有着锁A，然锁B属于锁A，也即B保护的资源（b）在A所保护的资源（a）中，如果此时因为占有A就去操纵a的
话，如果恰巧操纵到b，也是会出现问题（因为B已经释放了）


   

h123e

回复 13# sygspjlsj


    事实上这种代码在现实中是存在的，而且我也说了“如果没有6，7步的话，应该释放锁的顺序没有什么影响。”

另外，如果按照你说的“也即B保护的资源（b）在A所保护的资源（a）中”，明明一把锁可以搞定的事，非得搞两把锁
我认为写这种代码的人就是在作死啊。从来没有听说过两把锁保护同一个资源的。

sygspjlsj

回复 15# h123e
这样用锁，的确不符合逻辑，我也是照着上面有位老兄的回答来作答的。感觉这个问题大家还是没有什么结果。
有没有什么完整的实例代码具体问题来具体分析下。