Home/ Questions/Q 719171
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T05:36:41+00:00

I’m working on a heavily data-bound Win.Forms application where I’ve found some strange behavior.

  • 0

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 Creating a blocking Queue<T> in .NET?). 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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0