Threadpool, order of execution and long running operations

Question

I have a need to create multiple processing threads in a new application. Each thread has the possibility of being "long running". Can someone comment on the viability of the built in .net threadpool or some existing custom threadpool for use in my application?

Requirements :

Works well within a windows service. (queued work can be removed from the queue, currently running threads can be told to halt)

Ability to spin up multiple threads.

Work needs to be started in sequential order, but multiple threads can be processing in parallel.

Hung threads can be detected and killed.

EDIT:

Comments seem to be leading towards manual threading. Unfortunately I am held to 3.5 version of the framework. Threadpool was appealing because it would allow me to queue work up and threads created for me when resources were available. Is there a good 3.5 compatable pattern (producer/consumer perhaps) that would give me this aspect of threadpool without actually using the threadpool?

Answer 1

Your requirements essentially rule out the use of the .NET ThreadPool;

It generally should not be used for long-running threads, due to the danger of exhausting the pool.

It does work well in Windows services, though, and you can spin up multiple threads - limited automatically by the pool's limits.

You can not guarantee thread starting times with the thread pool; it may queue threads for execution when it has enough free ones, and it does not even guarantee they will be started in the sequence you submit them.

There are no easy ways to detect and kill running threads in the ThreadPool

So essentially, you will want to look outside the ThreadPool; I might recommend that perhaps you might need 'full' System.Threading.Thread instances just due to all of your requirements. As long as you handle concurrency issues (as you must with any threading mechanism), I don't find the Thread class to be all that difficult to manage myself, really.

Answer 2

I've done essentially the same thing with .Net 3.5 by creating my own thread manager:

1. Instantiate worker classes that know how long they've been running.
2. Create threads that run a worker method and add them to a Queue<Thread>.
3. A supervisor thread reads threads from the Queue and adds them to a Dictionary<int, Worker> as it launches them until it hits its maximum running threads. Add the thread as a property of the Worker instance.
4. As each worker finishes it invokes a callback method from the supervisor that passes back its ManagedThreadId.
5. The supervisor removes the thread from the Dictionary and launches another waiting thread.
6. Poll the Dictionary of running workers to see if any have timed out, or put timers in the workers that invoke a callback if they take too long.
7. Signal a long-running worker to quit, or abort its thread.
8. The supervisor invokes callbacks to your main thread to inform of progress, etc.