.NET ThreadPool clarification - Available vs idle threads

Question

Hi,

I'm a little confused about one aspect of the .NET ThreadPool: namely, how you can tell how many of its 'Available' threads are idle ones waiting to be reused, and how many haven't yet been created.

The summary for the GetAvailableThreads() method states that it:

Retrieves the difference between the maximum number of thread pool threads returned by the GetMaxThreads method, and the number currently active.

Any thread that is 'active' is busy working and therefore not available for reuse, but how many are 'available' for reuse versus 'available' because they haven't been created?

I know that the GetMinThreads() method returns the absolute minimum number of threads the framework will maintain in the pool for reuse, but that doesn't necessarily equate to the current number of idle threads - does it? I'm under the impression that idle threads will hang around in the ThreadPool and only be pruned back to the minimum if they go unused for some time.

This is important because, according to the docs:

When all thread pool threads have been assigned to tasks, the thread pool does not immediately begin creating new idle threads. To avoid unnecessarily allocating stack space for threads, it creates new idle threads at intervals. The interval is currently half a second, although it could change in future versions of the .NET Framework.

I want to check if my application is having to create an excessive number of 'new' threads in the pool - slowing it down - but I'm not sure how to do that without being able to figure out how many idle, ready-to-reuse threads I have hanging around.

Any ideas welcome. Thanks!

Answer 1

The ThreadPool does not have a way to determine how many threads are currently idle. That is, created but not actually doing anything.

My experience with the ThreadPool shows that it's pretty good about keeping threads around. I don't know if they've put logic in there to keep track of the average number of threads in use, but I've never noticed my programs waiting on thread creation. Except at startup, of course. One of my programs is often creating and running dozens of concurrent threads, and I don't see any delay in starting them up, even if the workload has been low for a period of time.

I would suggest that you instrument your application, keeping track of when you make the call to ThreadPool.QueueUserWorkItem, and when the work item actually starts. Something like this:

DateTime queueTime = DateTime.Now;
ThreadPool.QueueUserWorkItem(WorkItemProc, queueTime);

void WorkItemProc(object state)
{
    DateTime startTime = DateTime.Now;
    DateTime queueTime = (DateTime)state;
    TimeSpan elapsed = startTime - queueTime;
    // At this point, elapsed.TotalMilliseconds will tell you how long it took
    // between queuing the item and it actually being started.
    ...
}

If you find that it's taking too long to start your pool threads, then you should create your own managed thread, and use events or some other messaging mechanism to give it work.

Answer 2

I would suggest that this is a case of "If you have to ask, you are not using it correctly". If resource management is an issue, Than you should create a custom solutionb that is specifically geared to your performance need. The .net threadpool is a general tool.

it's designed for a collection of independent short-duration tasks.

The fact that the threadpool doesn't give you instrumentation to throttle it, is, for me, the best sign that you shouldn't do that. The thread pool is a connivance tool for standard situations. But not for any situation. And from your question, I believe, that not for yours.

I would suggest that you should read the post by Raymond Chen That I have linked above. And this post by Eric Lippert.