与从非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顺序问题