查找哪个模块阻止了UI线程

Question

This is a two part question:

• I am working on a big project where multiple plugins developed by different teams are loaded inside one common container shell. At times I can see that my UI updates are blocked as there are multiple parallel UI updates, i want to know if there is a way to find which component is blocking the ui thread

• In .net how can i create a separate UI thread which requires dedicated UI intensive work?

Much Appreciate your help. Thanks.

Answer 1

Use the debugger. Debug + Break All when you notice it blocking. Then Debug + Windows + Threads and select the main thread. The call stack window shows you what it is doing.

A corner case is where these plugins are using a lot of calls to Control.Begin/Invoke or Dispatcher.Begin/Invoke. Your UI thread is not blocked in this case, it is just being overwhelmed by requests to dispatch the delegate targets. And doesn't get around to doing its normal duties anymore, like repainting the windows and responding mouse and keyboard events. There's little you can do about this beyond working with the plugin authors to get them to mend their ways.

You've already got an UI thread, the thread that created the first window. Creating additional threads that have their own windows is possible but causes unsolvable problems with window Z-order (a window will disappear underneath the window of another app) and generous helpings of window interop threading misery.

Answer 2

Visual Studio 2010's (in the higher SKUs) include features to check for this. If you run your program under the Concurrency Profiler, you can see exactly which threads are waiting on which locks when the deadlock occurs. In addition, it will highlight the deadlock (I believe in bright red) to make it easy to track down.

Answer 3

One approach you can take (though it may require a bit of redesign) is to disallow all plugin logic from running in the UI thread. All operations that require updates to the UI must be routed through well-defined service interfaces that can interpret, dispatch and perhaps even throttle the UI updates. This is only practical if your plugins are not deeply UI-centric and you have a service model that allows you to isolate the data being manipulated by the plugins from the visualization of that data. Without knowing more about your application, I can't give more concrete recommendations.

Answer 4

Here are two possible solutions to the problem that I came up with quickly. I am sure there are other equally valid solutions though.

Option 1: Instead of using the push model (via the ISynchronizeInvoke methods) switch to a pull (or poll) model in which the UI queries the plugin for updates. This has the following advantages.

• It breaks the tight coupling between the UI and worker/plugin threads that Control.Invoke imposes.
• It puts the responsibility of updating the UI thread on the UI thread where it should belong anyway.
• The UI thread gets to dictate when and how often the update should take place.
• There is no risk of the UI message pump being overrun as would be the case with the marshaling techniques initiated by the worker/plugin thread.
• The worker/plugin thread does not have to wait for an acknowledgement that the update was performed before proceeding with its next steps (ie. you get more throughput on both the UI and worker/plugin threads).

Option 2: Have the plugin accept an ISynchronizeInvoke instance instead of an actual Form or Control . This special synchronizing object will be implemented using a dedicated thread and a queue that acts as buffer between the plugin and the UI. It will accept update messages via the normal Invoke or BeginInvoke methods, which means you can keep the plugin architecture and interfaces mostly intact, and then forward those messages on to the UI after some type of filtering, merging, and throttling operations have occurred. The number of update messages existing in the synchronizing object will ebb and flow as the UI and plugin threads work load changes. It could be smart enough to change its forwarding strategy as the rate of messages increase.