Multiple BackgroundWorkers

joe_pool_is

Contributor
Joined
Jan 18, 2004
Messages
507
Location
Longview, TX [USA]
I've found a very through example on the BackgroundWorker Class on MSDN here, but I have a question that it does not address.

I have at least three (3) different, time-consuming tasks that I'd like to use a BackgroundWorker object on: Two for database queries, and one for text validation.

Can a single BackgroundWorker object be used for all three (3) of these tasks? Some of the tasks do, on occasion, call on the other tasks.

The BackgroundWorker's DoWork method includes a sender object. Would the sender be the name of the function that I used to call the BackgroundWorker's RunWorkerAsync method?

Alternately, I could drop a separate BackgroundWorker component on the form for each of my time-consuming tasks, but this may not be necessary.
 
What do you get with the Background Worker that you do not get with System.Threading?

I played with the Backgorund worker and could not get what I wanted easily (update UI at points along the "work") so I ended up using a Thread with Delagates to update my UI thread.

Did I miss something with the background worker?
 
No, BackgroundWorkers suck.

I spent half the day re-tooling my code to work with these BackgroundWorker controls. Whenever I went to test the code, I found that these creatures never tell the parent when they are finished, and the code can't run them again until they tell the parent they are.

My code just sat there doing nothing! The object of using BackgroundWorker controls was so that some of the database pulling and lengthy text validation could be handled by the threads (I had one for the db and one of text validating). I never was able to enter the second character on my text because the validating thread never stopped checking the text! It never even entered my text validating routine. So I removed it and just left the database thread in there. Same thing. It never returned either.

So, after testing and banging around trying to get this to work, I spent the next several hours undoing all the BackgroundWorker garbage.

(we really need some sort of version control here at work, but ...)
 
The background worker component is a good solution for simple multi threading operations. However, if you already have another multi threading solution in place, it does not make sense to convert over to the background worker component. What's more, a background worker component can't perform more than one task at once, and it has limited functionality compared to other threading classes. If your problem is more complex then a solution using System.Threading would be more appropriate. You can use separate background workers for different tasks as long as each task will never need to run multiple times concurrently.

Also, the sender parameter is the object that directly raises an event. In this case, it would be the BackgroundWorker object itself.

What do you get with the Background Worker that you do not get with System.Threading?
Simplicity. The background worker component is designed to handle simple multi threading situations.

It was probably created in response to the extremely common problem of a GUI freezing while the program does processing. All you have to do is set a few properties and handle a few events. It has events for progress updates and completion and supports cancellation. For progress updates, you simply set WorkerReportsProgress to true, call BackgroundWorker.ReportProgress() from the background thread to report progress changes, and handle the ProgressChanged event in the UI thread.
 
Sure, you get some simplicity. I guess I should have been more clear, or asked a slightly different question.

At what point does it become more work to manage multiple backgroundworkers than to just use System.Threading in the first place?
 
Generally if you need to coordinate multiple activities then the back ground worker becomes more difficult. It was really put there to simplify the common situation of executing a single task in the background.
 
Back
Top