與從非GUI線程顯示MessageBox相關的問題

Question

我正在處理一個嚴重的數據綁定的Win.Forms應用程序，我發現了一些奇怪的行爲。該應用程序具有單獨的I/O線程，通過異步web請求接收更新，然後將其發送到主/ GUI線程，以處理和更新應用程序範圍的數據存儲（這又可以將數據綁定到各種GUI-元素等）。 Web請求另一端的服務器需要定期請求或會話超時。

我已經通過處理線程的問題等幾個嘗試的解決方案走了，我觀察到以下行爲：

1. 如果我使用Control.Invoke從我發送更新/ O-線程到主線程，此更新會導致MessageBox顯示主窗體的消息泵停止，直到用戶單擊確定按鈕。這也阻止了I/O線程繼續最終導致服務器超時。

2. 如果我使用Control.BeginInvoke從I/O線程（或多個）發送更新主線程的主窗體的消息泵不不停止，但如果更新的處理導致了一個消息是如圖所示，該更新的其餘部分的處理將暫停，直到用戶單擊確定。由於I/O線程繼續運行，並且消息泵繼續處理消息，因此可以在消息框完成之前調用幾個用於更新的BeginInvoke。這導致無法接受的失序更新。

3. I/O線程將更新添加到阻塞隊列（非常類似於Creating a blocking Queue<T> in .NET?）。 GUI線程使用Forms.Timer定期應用阻塞隊列中的所有更新。該解決方案既解決了阻塞I/O線程的問題，又解決了更新的順序性問題，即直到完成前一個更新纔會開始。但是，性能成本很低，並且在顯示更新時引入延遲，這在長期內是不可接受的。我希望主線程中的更新處理是事件驅動的而不是輪詢。

所以對我的問題。我應該怎麼做這：

1. 避免阻塞I/O線程
2. 保證更新完成了序列
3. 保持主消息泵運行，同時顯示一個消息框，爲的結果更新。

更新：請參見下面

Answer 1

這裏是我結束了與解決方案：

• I/O線程將所有更新放在線程安全/鎖定隊列中。
• 獨立的工作線程無休止地分離更新，然後開始將它們調入GUI線程。
• 在GUI-thread中響應更新顯示MessageBox現在用BeginInvoke完成。相比之前的（在3以上使用GUI的更新輪詢描述）

此解決方案具有以下優點：GUI而不是輪詢的

1. 事件驅動的更新。這給出了（理論上）更好的性能和更少的延遲。
2. GUI更新和I/O都不被消息框鎖定。

更新：似乎使用此解決方案顯示消息框時GUI-updates仍然被鎖定。這會在更正時更新。

更新2：通過將Invoke更改爲BeginInvoke，更新了針對工作線程的修復。

Answer 2

解決方案，使你有一個複雜的數據採集和處理的過程要保持運行，但隨後你在裏面插入一個消息。線程+調用中的任何內容都不會改變MessageBox是Modal的事實，並且您必須等待它關閉，從而使整個鏈依賴於用戶點擊某個內容。

所以，擺脫MessageBox，至少在主要路徑。如果處理的一部分確實需要用戶干預，那麼該部分必須位於單獨的線程上。

Answer 3

MessageBox本身泵送消息循環。這當然不會是Windows窗體消息循環。一切正常運行，但減去由Control.BeginInvoke（）發佈的委託調用請求的派發。只有Windows窗體消息循環可以做到這一點。

當在UI線程上進行MessageBox.Show（）調用時會發生這種情況。但不是當它在工作線程上進行時，消息隊列是每個線程屬性。如果您可以將Show調用委託給工作人員，那麼您可能會解決您的問題。

解決您的問題：

1. 你真正想要的正好相反：工作線程應該阻止。不阻塞會導致嚴重問題，BeginInvoke派發隊列將無限制地填滿。一個可能的技巧是計算BeginInvoke調用的數量，在委託目標中倒數。使用Interlocked類。

2. 確保BeginInvoke目標的執行順序。真正的問題可能與工作線程不同步有關。

3. 顯示線程上的消息框。

Answer 4

不要使用Forms.Timer從隊列中應用更新，而是使用另一個線程來執行更新。此線程持續監視隊列並（可能）告訴GUI何時使用新數據刷新自己（通過BeginInvoke）MessageBox可以從此隊列讀取器線程顯示 - 不必是GUI線程。

---

編輯：隊列消費者可以撥打Control.Invoke顯示消息框來解決z順序問題