1

I have a loop which needs to create an unspecified and indefinite amount of Background threads. The threads will then simply run to completion but some may need to be cancelled.

I originally planned to do this by declaring one backgroundWorker, adding it to a list, then newing the BackgroundWorker to begin the process again. However because the List.Add method runs by reference to the passed in object I am thinking that when I new the original BackgroundWorker, the thread referenced by the List will be lost (or worse).

My second thought was simply assigning my newed value to a element in an array (array[i] = new BackgroundWorker()) but this does not lend itself to an indefinite amount of threads.

Does anyone have any suggestions of a good way to manage these individual threads? Thanks in advance.

user912447
  • 696
  • 1
  • 11
  • 31
  • An array element would still contain only a reference to your object so `your second thought == your first thought`. Note that Lists use arrays internally; they just resize themselves upon reaching the threshold. – Saeb Amini Mar 23 '12 at 06:39

1 Answers1

6

Two comments - one micro, one macro.

First, it seems like the TPL will fit your stated goals. Using Task.Factory.StartNew(), you'll be able to spawn an arbitrary amount of operations which will run on background threads. Further, using the overloads that take a CancellationToken, you cancel operations to as fine a degree as you might wish. Note that a Task is not equivalent to a Thread - by default, Tasks run in ThreadPool threads (as do background workers, by the way). It's entirely possible that your tasks will end up in a queue waiting for a pooled thread to become available.

Second, the bigger comment.

You claim that you will have an unspecified and indefinite number of work items. That you would spawn a thread per item makes me a bit edgy - threads aren't cheap, and if you have a large number of work items you can starve your process by naively starting new threads.

Can you elaborate on what you need to do with these threads? I don't know what constitutes a work item for your project, but it's entirely possible that a producer/consumer setup with a fixed number of threads would meet your parallelization needs. .NET 4.0 makes it easy with the System.Collections.Concurrent classes.

EDIT in response to comment

The case of TCP connections is very nearly what I was thinking about when I wrote the second comment above. In this case, you are considering a potentially infinite consumption of a limited OS resource, namely open sockets. I hope that you will investigate non-blocking I/O. This MSDN page documents asynchronous reading from sockets, and this one talks about the larger asynchronous programming model in .NET.

For scalable TCP serving, a good discussion already exists on SO: peruse at your pleasure.

Community
  • 1
  • 1
Ben
  • 6,023
  • 1
  • 25
  • 40
  • Each thread will be a new TCP connection transfer coming in from peers. I plan on serializing transfers coming from individual peers, but my number of peers needs to be relatively infinite (one million is a little ridiculous, but I would much prefer it to be a very large number), which meant that I needed to potentially have infinite threads running. I imagine if it ends up bogging down with lots of concurrent transfers then I would impose some sort of concurrent transfer maximum and thus limit my max concurrent threads. – user912447 Mar 23 '12 at 06:20