c# - 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 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 streaming 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.

Answer 1

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.