How does the .NET ThreadPool work, and how does it decide how many threads to run?

1. Work item flow in detail

A worker's loop is roughly: local queue → global queue → steal from a random other worker → park (spin briefly, then wait on a semaphore).

2. Hill climbing

The controller samples throughput (completed items per interval) at different thread counts, effectively running a small optimisation:

count = target
every sample period:
    measure completions/sec
    if increasing threads improved throughput: keep going up
    else: move down

It works well for CPU-bound or mixed workloads where more threads can raise throughput. It reacts slowly to sudden blocking, because blocked threads don't produce clear throughput signals quickly. That's what the starvation mechanism covers.

3. Starvation detection (the gate thread)

A background "gate" thread periodically checks whether work items are being dequeued. If the pool is at its target, work is pending, and nothing has completed for a while, it adds a thread. This happens at a bounded rate so a burst of blocking doesn't create thousands of threads. In .NET 6+, when a pool thread blocks waiting on a task, the runtime can count it as "blocking" and compensate more aggressively, but each injected thread still costs memory and scheduling, and latency still rises.

4. SetMinThreads: what it really does

ThreadPool.SetMinThreads(workerThreads: 200, completionPortThreads: 200);

• Threads up to 200 are created without delay when work is waiting.
• It doesn't pre-create threads.
• Cost: more threads under blocking load, more memory, more context switching, slower GC suspension.
• Configuration equivalents: "System.Threading.ThreadPool.MinThreads" in runtimeconfig.json, or the MSBuild property ThreadPoolMinThreads.

Use it as an incident mitigation or for a known bursty legacy workload, never as the default fix.

5. Containers

• Environment.ProcessorCount reflects the CPU limit, so a 2-CPU pod gets a minimum of 2 workers.
• On small pods, a few blocked threads exhaust the minimum very quickly, which is why sync-over-async hurts more in Kubernetes than on a 32-core VM.
• DOTNET_PROCESSOR_COUNT can override what the runtime sees (use carefully).

6. Reading a starvation dump

> dotnet-dump analyze app.dmp
> threadpool                      # pool state: threads, queue, min/max
> parallelstacks                  # merged stacks: look for many threads at the same frame
   300 System.Threading.Monitor.Wait
   300 System.Threading.ManualResetEventSlim.Wait
   300 System.Threading.Tasks.Task.InternalWaitCore
   300 PricingClient.GetPrice  <-- .Result on an async call

The culprit is the frame just above Task.Wait/.Result.

7. Version notes

8. Try it yourself

1. Run the code example and watch thread count grow slowly while 64 blocking tasks drain.
2. Add ThreadPool.SetMinThreads(64, 64) before the loop and compare total time.
3. Run the async version and note it needs only a handful of threads.
4. Build a small ASP.NET Core endpoint that calls Task.Delay(500).Wait(); load it with bombardier -c 200, watch dotnet-counters, then fix it with await and compare.
5. Take a dump during the blocking test and run threadpool and parallelstacks.
6. Run the same test in a container with --cpus=1 and see how much faster starvation sets in.

using System.Diagnostics;
using System.Threading;

ThreadPool.GetMinThreads(out int minWorkers, out int minIo);
Console.WriteLine($"Min workers {minWorkers}, min IO {minIo}");

var sw = Stopwatch.StartNew();
var blocking = Enumerable.Range(0, 64)
    .Select(_ => Task.Run(() => Thread.Sleep(1000))) // blocks pool threads
    .ToArray();

while (!Task.WaitAll(blocking, 500))
{
    Console.WriteLine($"{sw.Elapsed.TotalSeconds:F1}s threads={ThreadPool.ThreadCount} " +
                      $"pending={ThreadPool.PendingWorkItemCount}");
}
Console.WriteLine($"Blocking version took {sw.Elapsed.TotalSeconds:F1}s");

sw.Restart();
await Task.WhenAll(Enumerable.Range(0, 64).Select(_ => Task.Delay(1000)));
Console.WriteLine($"Async version took {sw.Elapsed.TotalSeconds:F1}s, threads={ThreadPool.ThreadCount}");