Problems related to showing MessageBox from non-GUI threads

Question

I'm working on a heavily data-bound Win.Forms application where I've found some strange behavior. The app has separate I/O threads receiving updates through asynchronous web-requests which it then sends to the main/GUI thread for processing and updating of application-wide data-stores (which in turn may be data-bound to various GUI-elements, etc.). The server at the other end of the web-requests requires periodic requests or the session times out.

I've gone through several attempted solutions of dealing with thread-issues etc. and I've observed the following behavior:

1. If I use Control.Invoke for sending updates from I/O-thread(s) to main-thread and this update causes a MessageBox to be shown the main form's message pump stops until the user clicks the ok-button. This also blocks the I/O-thread from continuing eventually leading to timeouts on the server.

2. If I use Control.BeginInvoke for sending updates from I/O-thread(s) to main-thread the main form's message pump does not stop, but if the processing of an update leads to a messagebox being shown, the processing of the rest of that update is halted until the user clicks ok. Since the I/O-threads keep running and the message pump keeps processing messages several BeginInvoke's for updates may be called before the one with the message box is finished. This leads to out-of-sequence updates which is unacceptable.

3. I/O-threads add updates to a blocking queue (very similar to http://stackoverflow.com/questions/530211/creating-a-blocking-queuet-in-net/530228#530228). GUI-thread uses a Forms.Timer that periodically applies all updates in the blocking queue. This solution solves both the problem of blocking I/O threads and sequentiality of updates i.e. next update will be never be started until previous is finished. However, there is a small performance cost as well as introducing a latency in showing updates that is unacceptable in the long run. I would like update-processing in the main-thread to be event-driven rather than polling.

So to my question. How should I do this to:

1. avoid blocking the I/O-threads
2. guarantee that updates are finished in-sequence
3. keep the main message pump running while showing a message box as a result of an update.

Update: See solution below

Answer 1

So you've got a complicated data-acquisition and processing chain that you want to keep running but then you insert a MessageBox in there. Nothing in the Threading+Invoke will change the fact that a MessageBox is Modal and that you have to wait for it to close, making the whole chain dependent on the User to click something.

So, get rid of the MessageBox, at least in the main path. If a segment of the processing does require user intervention then that segment must be on a separate thread.

Answer 2

MessageBox itself pumps a message loop. That of course won't be the Windows Forms message loop. Everything runs as normal, but minus the dispatching of delegate invocation requests posted by Control.BeginInvoke(). Only the Windows Forms message loop can do that.

This happens when the MessageBox.Show() call is made on the UI thread. But not when it is made on a worker thread, message queues are a per-thread property. If you can get the Show call to be delegated to a worker, you probably solve your problem.

Addressing your questions:

1. You really want the opposite: the worker threads should block. Not blocking can cause major problems, the BeginInvoke dispatch queue will fill up without bounds. One possible trick is to count the number of BeginInvoke calls, count down in the delegate target. Use the Interlocked class.

2. The execution order of BeginInvoke targets is guaranteed. The real problem is probably related to having worker threads getting out of sync.

3. Show the message box on a thread.

Answer 3

Don't use Forms.Timer to apply updates from the queue but use another thread to do it. This thread continually monitors the queue and (maybe) tells the GUI when to refresh itself with new data (via BeginInvoke) The MessageBox can be shown from this queue reader thread - does not have to be GUI thread.

---

Edit: The queue consumer can call Control.Invoke to display the messageBox to get around z-order issue

Answer 4

Here is the solution I ended up with:

• I/O thread puts all updates on a thread-safe/locking queue.
• Separate worker-thread spins endlessly Dequeing updates and then BeginInvoke'ing them into the GUI-thread.
• Display of MessageBox in GUI-thread in response to updates is now done with BeginInvoke.

This solution has the following benefits compared to the previous (described in 3. above using polling for GUI-updates):

1. Event-driven update of GUI rather than polling. This gives both a (in theory) better performance and less latency.
2. Neither GUI-updates nor I/O are locked by the Message Box.

Update: it seems that GUI-updates are still locked while a messagebox is shown using this solution. Will update when this is fixed.

Update 2: updated with fix for the worker-thread by changing Invoke to BeginInvoke.