Multithreaded service, BackgroundWorker vs ThreadPool?

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 questions about this issue.

1. Is BackgroundWorker really intended for use just in WinForms applications or is this just nonsense, how exactly is it tuned to this effect?
2. I've read about ThreadPools in this question and this one. I'm not exactly sure how much it is a problem for me that the threads would last somewhere between half a second and a few seconds. Is this reason enough to look somewhere else?
3. Am I best off just creating the background threads myself?

The real-life service will poll the database for a list of pending requests, execute threads for each of those requests (limited to a certain amount of concurrent threads) and each thread will be checking if some data exists in a database, retrieve it if it does, or download it from a s开发者_JS百科treaming API, store it, and return that data. The downloading would be the part that consumes the most time.

I would really like this question to be answered for .NET 3.5 Framework, but if there are better or more efficient ways to accomplish this under .NET 4.0, I would like to read about them too. Links with more info are also very much welcome.

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.

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 :).

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).

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

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.