Take the 2-minute tour ×

I have a C# Add-In for a UML modelling product that automatically draws diagrams and maintains them. I am processing larger scale enterprise models with over 6000 diagrams. This takes a long time (even on faster machines). So I created a version that uses the Background worker thread to run the "batch" portion of the job while the "foreground" has a modal dialogue that allows me to stop the processing early. Otherwise, due to the UI of the modelling program I can't send the "STOP" message to the Add-In.

The background version seems to take twice as long as the single thread version. Actually, I was expecting that the background worker thread version would be multi-threaded but from what probing I have been able to do it's not actually running in a separate thread.

The Modal dialog and the Add-In communicate correctly so the two pieces of functionality appear to be on separate threads. The batch runs under .RunWorkerAsync() through the DoWork method. But if I place traces in the code they report that there are not running on separate threads (since .Invoke Required is set to false).

I would have expected a small amount of overhead, but not this much (100%).

What's going on? Should I be moving to true multi-threading (as opposed to BackgroundWorker)?

TIA, Paolo

share|improve this question
A BackgroundWorker should be fine here. We will need to see some code to find your problem here. –  Øyvind Knobloch-Bråthen Nov 28 '11 at 6:24
add comment

1 Answer

up vote 2 down vote accepted

There can be several reasons, unless we see some code it's hard to help. but nevertheless I have some suggestions:

First of all, a background worker doesn't mean that is *multithreaded", it means that one thread is doing the job in the background instead of the main UI thread. If the thread you are pushing in the background is doing a lot of UI, then you will have a lot of synchronistion context switches which will make the background thread real slow.

share|improve this answer
Thanks, I guessed background worker wasn't true multi-thread. The background task has to use the API of the modelling program so I can't really not generate UI activity. Among other things, it will open and close diagrams and display them on the main work surface of the tool - in addition (possibly) updating the size and location of objects on the diagrams all through the API. I guess that means I need to go and create a proper multi-thread situation. –  PaoloFCantoni Nov 28 '11 at 7:13
@PaoloFCantoni: You've got it. –  Fischermaen Nov 28 '11 at 7:22
add comment

Your Answer


