我尝试从其他线程使用WIN32 API遇到了死锁。 在我的应用程序中需要额外的线程来提高帧速率。 它实际上有帮助，然而，我几乎在所有的系统function中遇到了死锁：
:: ShowWindow :: MoveWindow :: UpdateWindow
我知道ShowWindow（），例如，可以replace为ShowWindowAsync（），它确实解决了这个问题，但是，在MoveWindow（）和UpdateWindow（）中没有这样的select。
有人遇到这些问题，解决scheme是什么？
谢谢！
术语“死锁”描述了一个非常具体的事情，两个线程等待访问被另一个锁定的资源。 没有迹象表明这是你的情况（或者是在那里）发生了什么事情，那么你究竟遇到了什么？ 另外，你想用多线程来达到什么目的呢？
在任何情况下，保持在一个单一的线程的用户界面，使用SendMessage（）＆Co通知该线程发生在后台线程中的任何事件。 或者，您也可以使用计时器轮询某些状态更改。 这样，你就安全了，你的应用程序不应该锁定（至少不是因为使用不同线程的UI）。
为了更精确一点，你必须保持一个窗口的消息循环和所有的子窗口在一个线程中。 您可以创建多个窗口，并从他们自己的线程处理每个窗口，但不要混合调用。 实际上，这种区别并不重要，因为很少有应用程序创建多个窗口（并且没有，例如消息框或其他对话框不计数）。
所有引用的API函数都有一些共同之处，那就是它们向目标窗口发送（！）一些消息。 UpdateWindow可能是最明显的，因为它需要发送WM_PAINT。 还要注意，它“发送”消息，不会发布到队列中（对于UpdateWindow，MSDN文档会明确地调用这个消息，对于其他消息可能不那么明显）。
另外请注意，Windows在某些注释中暗含的线程亲和性 。 除此之外，这意味着到那个窗口的消息只能在一个线程上接收/发送。 如果您将消息发送到另一个线程的窗口，则操作系统将留下该任务以确定何时应该分派该消息（即调用窗口过程）。 这个（调度传入的发送消息）只发生在某些API调用期间，在此期间可以认为使用随机消息来调用窗口过程是安全的。 相关时间在GetMessage和PeekMessage *期间。
所以如果你的窗口拥有线程（也被称为UI线程）正在抽取消息，传入的发送消息也会被快速地分派。 从你的问题看来，然而，你的UI线程目前正忙。 如果第二个线程调用其中一个函数，它将阻塞，直到第一个线程提供发送消息的机会。
正如其他人所说的，将用户界面代码保留在一个专用的UI线程上通常是一个好主意（尽管例外 – 像往常一样 – 证明规则）。 对于一个好的用户体验来说，拥有线程的窗口总是对消息作出响应是绝对必要的。 如果您的UI线程也必须等待一些同步对象，您可能会发现MsgWaitForMultipleObjects有帮助。
*列表可能不完整。