Linux 如何处理死锁

Linux 如何处理死锁,第1张

处理死锁的策略

1.忽略该问题。例如鸵鸟算法,该算法可以应用在极少发生死锁的的情况下。为什么叫鸵鸟算法呢,因为传说中鸵鸟看到危险就把头埋在地底下,可能鸵鸟觉得看不到危险也就没危险了吧。跟掩耳盗铃有点像。

2.检测死锁并且恢复。

3.仔细地对资源进行动态分配,以避免死锁。

4.通过破除死锁四个必要条件之一,来防止死锁产生。

检测死锁的代价很大。所有的类unix系统包括Linux对死锁不作任何处理,这是因为基于成本的考虑.选择鸵鸟算法

让我来告诉你答案!设置状态变量lock=0,在占用资源的函数中,设置lock=1;并在处理结束后设lock=0.

比如:

boollock=0

intscan()

{

while(lock!=0)//循环检测,直到资源释放才执行下面的语句

lock=1//锁定资源

...//具体的执行扫描的语句

lock=1//释放资源

return0

}

这个方法容易实现,但是占用CPU,假定其他线程正在占用扫描仪,那么这个线程就会在自己的时间片内不停的执行while语句直到对方释放扫描仪。由此造成了浪费。

现在流行的做法是通过中断信号来做,那是一本书的内容,建议看linux内核编程方面的书。

找出调用栈

使用gdb attach nmsagent所在的进程,在gdb中使用 info threads显示所有线程

gdb gdb>attach 2907

gdb>info threads

得到如下结果,可以发现2909线程的编号是12

13 Thread 0xad5f2b70 (LWP 2908) 0x004ef0d7 in mq_timedreceive () from /lib/tls/i686/cmov/librt.so.1

12 Thread 0xad58eb70 (LWP 2909) 0x006e0422 in __kernel_vsyscall ()

11 Thread 0xad52ab70 (LWP 2910) 0x006e0422 in __kernel_vsyscall ()

10 Thread 0xad4f8b70 (LWP 2911) 0x006e0422 in __kernel_vsyscall ()

9 Thread 0xad4c6b70 (LWP 2912) 0x006e0422 in __kernel_vsyscall ()

8 Thread 0xad3feb70 (LWP 2913) 0x004ef0d7 in mq_timedreceive () from /lib/tls/i686/cmov/librt.so.1

7 Thread 0xace08b70 (LWP 2914) 0x004ef0d7 in mq_timedreceive () from /lib/tls/i686/cmov/librt.so.1

6 Thread 0xac607b70 (LWP 2915) 0x006e0422 in __kernel_vsyscall ()

5 Thread 0xac5e6b70 (LWP 2916) 0x006e0422 in __kernel_vsyscall ()

4 Thread 0xac361b70 (LWP 2917) 0x006e0422 in __kernel_vsyscall ()

3 Thread 0xac2fdb70 (LWP 2918) 0x006e0422 in __kernel_vsyscall ()

2 Thread 0xac1fcb70 (LWP 2919) 0x004ef0d7 in mq_timedreceive () from /lib/tls/i686/cmov/librt.so.1

* 1 Thread 0xb78496d0 (LWP 2907) 0x006e0422 in __kernel_vsyscall ()

使用thread 切换线程,使用bt显示线程栈

gdb>thread 12 gdb>bt

得到如下线程栈

#0 0x006e0422 in __kernel_vsyscall ()

#1 0x001cca26 in nanosleep () from /lib/tls/i686/cmov/libc.so.6

#2 0x001fc2dc in usleep () from /lib/tls/i686/cmov/libc.so.6

#3 0x0806b510 in OspTaskDelay ()

#4 0x0805c710 in CDispatchTask::NodeMsgSendToSock() ()

#5 0x0805cc74 in DispatchTaskEntry ()

#6 0x0806a8e9 in OspTaskTemplateFunc(void*) ()

#7 0x00d4780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0

#8 0x002027ee in clone () from /lib/tls/i686/cmov/libc.so.6

ps + strace

得到进程ID 21465 ps -e |grep cmu 4996 ? 00:00:25 cmu_fjga_sp3 21465 pts/5 00:08:10 cmu

得到线程时间, 其中最占CPU的是 EpollRecvTask 21581

ps -eL |grep 21465

21465 21579 pts/5 00:00:00 CamApp

21465 21580 pts/5 00:00:00 TimerMan Task

21465 21581 pts/5 00:09:02 EpollRecvTask

21465 21582 pts/5 00:00:00

使用 strace -p 21581 得到线程栈


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/8303435.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-15
下一篇 2023-04-15

发表评论

登录后才能评论

评论列表(0条)

保存