0

In C#, I am considering creating an array of BackgroundWorkers to work on an time-intensive problem. Each thread could last minutes.

Apparently though, 'threadpool' threads (which is what the BackgroundWorker uses) are not ideally meant to last longer than half a second. I quote:

It is important that you use a thread pool thread only when the work it does is limited, ideally not taking more than half a second.

I'd like to know the reasoning behind this, and also ask what the consequences are if I were to go ahead regardless. Is this because it's slower compared to Thread/Task, or is it memory-related, or is it because it bogs the system down, or is it some other issue?

One further comment from that post:

"It is therefore best suited for short bursts for work, not anything where performance matters.".

From my experimentation, I have not found this to be the case. For my (embarrassingly-parallel) problem at least, on a quadcore system and testing multiple times, 4 BackgroundWorkers results in no apparent performance degradation relative to using 4 Threads instead (and either of those makes makes the program run almost 4x as fast as using just a single BackgroundWorker or Thread as expected).

As a BackgroundWorker is simpler to use, from my perspective, I see no issue with keeping with that. If I am mistaken, please convince me otherwise.

Community
  • 1
  • 1
Dan W
  • 3,520
  • 7
  • 42
  • 69
  • What version of C# / .NET? The recommendations for parallel stuff is to use `Tasks` and or `async`. Check http://stackoverflow.com/questions/7913034/best-practice-longrunning-task-creation for long running tasks. If you must, you can create and manage own threads via `System.Threading.Thread` – rbm May 12 '16 at 10:48
  • 4 is a happy number, everybody has at least a dual-core processor with hyper-threading enabled. 5 is where the problems start. Like also using a System.Timers.Timer, the Elapsed event is going to be quite sluggish. Not a good practice. – Hans Passant May 12 '16 at 11:14
  • @HansPassant: Using BackgroundWorkers, would 5 threads be a problem for an eight-core machine? Obviously, I don't intend to use 5 threads for a 4-core machine. – Dan W May 12 '16 at 11:31
  • Well, that should be a little obvious. What is not obvious is why you intentionally not use the compute resources available and whether you can demand that your user buys the kind of hardware that keeps your program happy. You have to put stuff like that in your prerequisites. Or do it right. – Hans Passant May 12 '16 at 11:43
  • @HansPassant: I'm a little confused. Are you saying that 5 threads on a quadcore using `Task` provides the user a better experience than 5 threads on a quadcore using `BackgroundWorker`? – Dan W May 12 '16 at 11:52
  • @rbm: .NET 3.5 preferably. But I'm willing to switch to .NET 4.0 and using Task if it can be shown that BakgroundWorkers are less efficient. – Dan W May 12 '16 at 11:57
  • No. There is no difference, albeit that Task allows you to use TaskCreationOptions.LongRunning to force it onto a Thread. BGW has no such option. – Hans Passant May 12 '16 at 11:59
  • @HansPassant: So yes that would indicate than BGWs are not suitable for long running tasks. But I am still unsure why this is the case. For example, would 16 threads running on a 16 core machine benefit using `Task` over BGW? And if so, in what way? – Dan W May 12 '16 at 12:01

0 Answers0