三个月经话题，谁能有良策？

芙蓉

搞C这么多年，竟然还没把这几个问题玩转。
1. 内存泄漏，2. 内存不够何如？
这两个问题不讨论了，讨论再好也不能保证每个人都做得好。

3. 如何避免线程死锁？
   尤其给一堆乱七八糟许多个lock, semaphore在一起的程序的时候，十分难解.
   按同样的顺序上锁, 这是没错的. 但线程一多, 就很难搞清.
   还有semaphore, condition存在的情况下, 还有因为不断尝试获取资源而锁住的情况下.
   如何彻底消除死锁隐患？各位安有良策?

linternt

好像除了锁机掉，还没想过太好的办法！

aero

漏了堵，不够了要，好像确实没啥好办法。

死锁也是很头疼的事情。貌似OS现在对这个解决得也不很好。是不是理论上就没啥好办法啊？

芙蓉

原帖由 linternt 于 2008-7-22 09:59 发表
好像除了锁机掉，还没想过太好的办法！

What is 锁机掉?

芙蓉

原帖由 aero 于 2008-7-22 10:00 发表
漏了堵，不够了要，好像确实没啥好办法。

死锁也是很头疼的事情。貌似OS现在对这个解决得也不很好。是不是理论上就没啥好办法啊？

感觉就是像堵漏员啊, 才会有此一贴.
出了问题才想去堵, 怕就怕不出问题, 头痛头痛

cjaizss

有无死锁是可以证明的。死锁总是发生在两个进/线程对某两个资源的获取方向相反，且在这两个资源的获取动作的当中，不存在机制让两个进/线程同步，于是我们就可以用图论的方法解决这个问题了

芙蓉

原帖由 cjaizss 于 2008-7-22 10:11 发表
有无死锁是可以证明的。死锁总是发生在两个进/线程对某两个资源的获取方向相反，且在这两个资源的获取动作的当中，不存在机制让两个进/线程同步，于是我们就可以用图论的方法解决这个问题了

我在考虑这个问题,
是否有办法对 mutex, semaphore, condition 做一个包装,
让他自然就能检测出这个 "获取方向相反" 的情况?
(对于或取其他有限的资源, 都伴随着semaphore进行.)

这样应该可以做到对死锁进行 "预警".

目前我有用此法包装了一个mutex, 然而对于semaphore和condition,
俺还没想出来怎么包装.

cjaizss

原帖由 芙蓉 于 2008-7-22 10:16 发表


我在考虑这个问题,
是否有办法对 mutex, semaphore, condition 做一个包装,
让他自然就能检测出这个 "获取方向相反" 的情况?
(对于或取其他有限的资源, 都伴随着semaphore进行.)

这样应该可以做到对死 ...

在设计的时候，用数学证明。

芙蓉

原帖由 cjaizss 于 2008-7-22 10:25 发表

在设计的时候，用数学证明。

啊...已經mission impossible了.
因爲是debug別人程序的問題.

cjaizss

可以借助计算机来证明这点，构造一个占资源、放资源的图，判断内部有没有某种形式的环。