BackgroundWorker and Threads

Question

What are the pros and cons in using the either for achieving a given task.

The million dollar question is which one to use and when?

Many Thanks.

Answer 1

The BackgroundWorker class simply provides events that are switched to the context of the UI thread for you, but don't be confused; the DoWork event (which is where you actually, well, do the work) is still executed in the context of another thread (as that's the point of the whole thing) and performing any kind of UI interaction or update there will throw an exception at best, and crash at worst. The BackgroundWorker should be used on forms when you're trying to do something that requires a UI update and whose scope doesn't extend beyond that of the form. For other background operations, consider either using the ThreadPool (for short-lived operations) or creating your own Thread.

The BackgroundWorker provides convenience with the ProgressChanged event, but don't get too comfortable and start doing UI updates in DoWork.

Answer 2

Have a look at this great threading overview:

[The BackgroundWorker] provides the following features:

• A "cancel" flag for signaling a worker to end without using Abort

• A standard protocol for reporting progress, completion and cancellation

• An implementation of IComponent allowing it be sited in the Visual Studio Designer Exception handling on the worker thread

• The ability to update Windows Forms and WPF controls in response to worker progress or completion.

The last two features are particularly useful – it means you don't have to include a try/catch block in your worker method, and can update Windows Forms and WPF controls without needing to call Control.Invoke.

Answer 3

Threads only when you don't have to work with a UI (WinForms or WPF) and background workers when you do have to deal with a UI.

You avoid a lot of problems with UIs and background workers.

Answer 4

The BackgroundWorker class is an easy way to add a thread to a Form to perform some heavy operation without blocking the UI. You could do the same with a thread but with slightly more coding.

Answer 5

I use to associate BackgroundWorker as a wrapper for what Threads would do. So I use BackgroundWorker on GUI works, and Threads on more specialized or dirty jobs (Windows Services, etc)

Answer 6

If by "Threads" you mean explicitly using the System.Threading.Thread class to create, configure and kick off your own threads, then the answer is that doing this is more work on your part, involves more cpu cycles than just pulling a thread from the thread pool, (wjhich is what the other techniques do), but it gives you more flexibility, as it allows you to specify thread priority, and several other characteristics that using Thread Pool threads does not afford you.

The "Thread Pool" approach is more appropriate when the number of threads required is not known at design time. The pool initially contains a small number of threads, “ready” for you to call upon them. It can dynamically create new threads on demand, and it manages creation, coordination, and deletion of unused threads for you. There are three mechanisms you can use to access and use threads from the pool.

1. Using Delegate.BeginInvoke() (the most common technique)
2. Using timers (several variations)
3. System.Threading.ThreadPool provides several other features (BackGroundWorker class, QueueUserWorkItem(), etc.).