有人碰到了一个死锁问题，找到我们想请我们看看，这个是关于应用程序用户界面相关的死锁问题。
我也不清楚他为什么会找上我们，可能是因为我们经常会和窗口管理器打交道吧。
下面，我们来看看死锁的两个线程。
>> 请移步至 www.topomel.com 以查看图片 <<
调试死锁的问题在于，你通常不太需要了解具体的技术细节。一旦你踏入大门，诊断在很大程度上是机械化的。(尽管有时很难踏入大门。)
让我们先看看线程 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)是一款绿色软件，主要面向经常使用电脑的朋友。它提供了各种提升办公效率的小功能，同时操作上尽可能地简单方便。
我想：你值得拥有。
