死锁调试技巧:工作线程和用户界面线程

死锁调试技巧:工作线程和用户界面线程

作者:BlogUpdater |  时间:2024-05-10 |  浏览:122 |  评论已关闭 条评论

有人碰到了一个死锁问题,找到我们想请我们看看,这个是关于应用程序用户界面相关的死锁问题。

我也不清楚他为什么会找上我们,可能是因为我们经常会和窗口管理器打交道吧。

下面,我们来看看死锁的两个线程。

调试死锁的问题在于,你通常不太需要了解具体的技术细节。一旦你踏入大门,诊断在很大程度上是机械化的。(尽管有时很难踏入大门。)

让我们先看看线程 0。

它正在等待一个临界区。该临界区的所有者是线程 1。我是怎么知道的?
好吧,我本可以调试它,或者我可以用我的第六感说,”天哪,那个函数叫做 LogMsg,看,函数 LogMsg 里面有另一个线程。我敢打赌,该函数正在使用一个关键部分,以确保一次只有一个线程使用它。”

好的,现在我们知道,第一个线程 0 正在等待线程 1。线程 1 在做什么?

好吧,它回到了 LogMsg 函数中的关键部分,然后它做了一些文本处理,哦,看,它正在执行 SetScrollInfo。SetScrollInfo 进入 comctl32 并最终生成 SetWindowLong。

应用程序传递给 SetScrollInfo 的窗口由线程 0 拥有。我又是怎么知道?
好吧,我本可以调试它,或者再次使用我的第六感说,”天哪,滚动信息的变化导致了窗口样式的改变,线程正试图通知窗口样式的变化。该窗口显然属于另一个线程;否则我们一开始就不会被卡住,而且鉴于我们只看到两个线程,对于其他线程可能是什么,没有太多选择!”

在这一点上,我们就看到了死锁的场景。线程 0 正在等待线程 1 退出临界区,但线程 1 正在等待线程 0 处理样式更改消息。

这里发生的事情是,程序在持有临界区时发送了一条消息。

由于消息处理可以触发钩子和跨线程活动,因此在发送消息时不能保留任何资源,因为钩子或消息接收者可能想要获取你拥有的资源,从而导致死锁。

总结

这个死锁场景似曾相识,在拓扑梅尔智慧办公平台 (Topomel Box) 中,我们大量的使用了工作线程,当工作线程需要操作用户界面的时候,我们简单的遵循一个规则:向目标窗口投递 (Post) 消息,而不是直接使用 Win32 API 直接对用户界面进行操作,甚至我们也会十分谨慎的使用发送(Send)消息这样一种阻塞调用。

我们始终遵守这样一则铁律。

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一,里面有很多关于Windows的小知识,对于广大Windows平台开发者来说,确实十分有帮助。
本文来自:《Psychic debugging: The first step in diagnosing a deadlock is a simple matter of following the money》

最近我写了个东西

正如你们所知道的,拓扑梅尔智慧办公平台(TopomelBox)是一款绿色软件,主要面向经常使用电脑的朋友。它提供了各种提升办公效率的小功能,同时操作上尽可能地简单方便。
我想:你值得拥有。

标签:

评论已关闭。