使用不同的線程時Win32 API死鎖

Question

嘗試從其他線程使用WIN32 API時遇到死鎖。 我的應用程序中需要其他線程來提高幀速率。 它實際上有幫助，但是，我幾乎在所有系統功能中都陷入僵局：

:: ShowWindow :: MoveWindow :: UpdateWindow

我知道ShowWindow（）例如可以用ShowWindowAsync（）代替，它確實解決了問題，但是，MoveWindow（）和UpdateWindow（）中沒有此類替代方法。

有人遇到過這些問題，什么是解決方案？

謝謝！

Answer 1

術語“死鎖”描述了一個非常具體的事物，兩個線程等待訪問被另一個鎖定的資源。 沒有跡象表明您的情況正在發生（或存在？），那么您正在經歷的到底是什么？ 另外，多線程到底要實現什么？

無論如何，將UI保留在單個線程中，使用SendMessage（）＆Co將該線程在后台線程中發生的任何事件通知該線程。 另外，您也可以使用計時器來輪詢某些狀態更改。 這樣一來，您就安全了，並且您的應用程序不應鎖定（至少不是因為使用來自不同線程的UI）。

為了更精確一點，您必須將一個窗口及其所有子窗口的消息循環保持在單個線程中。 您可以創建多個窗口並從它們自己的線程中處理每個窗口，但不要混用調用。 實際上，這種區別並不重要，因為很少有應用程序會創建多個窗口（並且不會，例如，不包含消息框或其他對話框）。

Answer 2

您引用的所有API函數都有一個共同點，就是它們向目標窗口發送（！）一些消息。 UpdateWindow可能是最明顯的，因為它需要發送WM_PAINT。 還要注意，它“發送”消息並且沒有發布到隊列中（對於UpdateWindow，MSDN文檔明確地指出了這一點，對於其他消息則可能不太明顯）。

還要注意，在某些注釋中提到的窗口具有線程相似性 。 除其他外，這意味着到該窗口的消息僅在一個線程上被接收/調度。 如果將消息發送到另一個線程的窗口，則操作系統將留有任務來確定何時應分派該消息（即，調用窗口過程）。 僅在某些API調用期間發生這種情況（調度傳入的已發送消息），在此期間可以假定使用隨機消息安全地調用窗口過程是安全的。 相關時間是在GetMessage和PeekMessage *期間。

因此，如果您擁有窗口的線程（也稱為UI線程）正常泵送消息，則也將迅速調度傳入的已發送消息。 但是從您的問題看來，您的UI線程當前正在繁忙。 如果第二個線程然后調用所述功能之一，則它將阻塞，直到第一個線程有機會調度發送的消息。

正如其他人所說，將用戶界面代碼保留在一個專用的UI線程上通常是一個好主意（盡管例外情況-一如既往地證明了規則）。 並且（為了獲得良好的用戶體驗）絕對有必要讓擁有窗口的線程始終響應消息。 如果您的UI線程也必須等待某些同步對象，則MsgWaitForMultipleObjects可能會有所幫助。

*列表可能不完整。