Multithreaded service, BackgroundWorker vs ThreadPool?

Question

I have a .NET 3.5 Windows Service. I\'m testing with a small application that just sleeps threads after starting them, for random timespans of 300 to 6500ms. I have various

Answer 1

BackgroundWorker was designed to simplify interaction of the task working in the background thread with the UI. You will see the great answer on when to use BackGroundWorker, ThreadPool and simply Thread at BackgroundWorker vs background Thread

I think it answers the question :).

Answer 2

The value in BackgroundWorker is that it can raise its ProgressChanged and RunworkerCompleted event on the thread that created its instance. Which makes it very convenient in programs that cannot support free threading.

For this to work properly, it is however required that the SynchronizationContext.Current property references a non-default synchronization provider. A provider which is responsible for marshaling calls from one thread to another. The .NET framework has two providers that are readily available: System.Windows.Forms.WindowsFormsSynchronizationContext and System.Windows.Threading.DispatcherSynchronizationContext. These providers handle synchronization for, respectively, Winforms and WPF.

There's a connection, Winforms and WPF are both class libraries that have a threading problem. Both implement GUIs and Windows based graphical user interfaces are fundamentally thread-unsafe. Windows windows can only be updated from the thread that created them. In other words, these custom synchronization providers exist because there's a dire need for them. Also notable is that they work by taking advantage of the way UI threads work. A UI thread executes code in an event driven way, pumping a message loop to receive notifications. The synchronization provider can inject calls to event handlers using this mechanism. This is no accident.

Back on topic, a Windows service has no such facility. It doesn't have a GUI and doesn't install a custom synchronization provider. As such, BackgroundWorker provides no feature that's useful in a service. Without the custom synchronization provider, the default provider simply runs events on a threadpool thread. Which is not useful, you might as well fire the event from your worker thread. Getting events to run on another specific thread is very difficult to achieve, unless you recreate the message loop mechanism or hook into the Winforms plumbing and create a simulated UI thread using an invisible window. Which is not entirely uncommon btw.

Answer 3

I wrote up a fairly exhaustive overview of various implementations of asynchronous background tasks on my blog. The summary is: prefer Task; the second choice would be BackgroundWorker; and only use Thread or ThreadPool.QueueUserWorkItem if you really need to.

Reasons: it's easier to detect and recover from errors, and it's easier to synchronize back to a UI.

To answer your specific questions:

BackgroundWorker works in any host, including WinForms and WPF (and even ASP.NET!), because it is based on SynchronizationContext. Windows services do not have a SynchronizationContext, but you can use ActionThread from the Nito.Async library, which comes with a SynchronizationContext.

If I read your question correctly, you currently have Threads and are considering ThreadPool and BackgroundWorker. Of those choices, I recommend BackgroundWorker, but if you have the chance, use the new Task class in .NET 4.0 (if you install Microsoft Rx, you can also use Task in .NET 3.5).

Answer 4

Definitely not Backgroundworker for a service

You should go with Tasks in the System.Threading.Tasks namespace, could also use tasks Parallel threading execution

http://msdn.microsoft.com/en-us/library/dd460717.aspx
I quote: "Starting with the .NET Framework 4, the TPL is the preferred way to write multithreaded and parallel code."

Some readings:
http://msdn.microsoft.com/en-us/library/dd997413%28VS.100%29.aspx

Start here:
http://msmvps.com/blogs/brunoboucard/archive/2010/04/09/parallel-programming-task-oriented-parallel-part-1.aspx
http://msmvps.com/blogs/brunoboucard/archive/2010/05/18/parallel-programming-in-c-4-0-task-oriented-parallel-programming-part-2.aspx
http://msmvps.com/blogs/brunoboucard/archive/2010/11/06/parallel-programming-with-c-4-0-part-3.aspx

More examples
http://www.dotnetcurry.com/ShowArticle.aspx?ID=489
http://www.dotnetfunda.com/articles/article984-parallel-compting-in-csharp-40-.aspx

Answer 5

I think that your third choice is best. I've done similar things with Windows services in .Net 3.5 and found that creating my own threads was a good way to go, particularly with threads that were interfacing with web services.

I create a worker instance and give it a callback that signals the service when it's done. I store ready-to-run threads in a Queue and peel them off according to the maximum number of concurrent threads that I want. If all you care about is the number of running services, you can keep track of them with a simple counter. I prefer to store each running worker instance in a Dictionary keyed by the thread's ManagedThreadId so that I can readily signal each instance if I want to shut it down cleanly. It's also convenient for polling running instances to check status.