Thread vs ThreadPool

The .NET managed threadpool: -

• Sizes itself based on the current workload and available hardware
• Contains worker threads and completion port threads (which are specifically used to service IO)
• Is optimised for a large number of relatively short-lived operations

Other thread pool implementations exist that might be more appropriate for long-running operations.

Specifically, use a thread pool to prevent your app from creating too many threads. The most important feature of a threadpool is the work queue. That is, once your machine is sufficiently busy, the threadpool will queue up requests rather than immediately spawn more threads.

So, if you will create a small, bounded number of threads create them yourself. If you cannot determine up-front how many threads might be created (e.g. they're created in response to incoming IO), and their work will be short-lived, use the threadpool. If you don't know how many, but their work will be long-running, there's nothing in the platform to help you - but you might be able to find alternative threadpool implementations that fit.

also

new Thread().Start()

spawns Foreground thread that will not die if you close your program. ThreadPool threads are background threads that die when you close the app.

Thread pool will provide benefits for frequent and relatively short operations by

• Reusing threads that have already been created instead of creating new ones (an expensive process)
• Throttling the rate of thread creation when there is a burst of requests for new work items (I believe this is only in .NET 3.5)

  • If you queue 100 thread pool tasks, it will only use as many threads as have already been created to service these requests (say 10 for example). The thread pool will make frequent checks (I believe every 500ms in 3.5 SP1) and if there are queued tasks, it will make one new thread. If your tasks are quick, then the number of new threads will be small and reusing the 10 or so threads for the short tasks will be faster than creating 100 threads up front.

  • If your workload consistently has large numbers of thread pool requests coming in, then the thread pool will tune itself to your workload by creating more threads in the pool by the above process so that there are a larger number of threads available to process requests

  • check Here for more in depth info on how the thread pool functions under the hood

Creating a new thread yourself would be more appropriate if the job were going to be relatively long running (probably around a second or two, but it depends on the specific situation)

@Krzysztof - Thread Pool threads are background threads that will stop when the main thread ends. Manually created threads are foreground by default (will keep running after the main thread has ended), but can be set to background before calling Start on them.

I was curios about the relative resource usage for these and and ran a benchmark on my 2012 dual-core Intel i5 laptop using .net 4.0 release build on windows 8. Thread Pools took on average 0.035ms to start where Threads took an average of 5.06ms. In other words Thread in the pool started about 300x faster for large numbers of short lived threads. At least in the tested range (100-2000) threads, the total time per thread seemed pretty constant.

This is the code that was benchmarked:

    for (int i = 0; i < ThreadCount; i++) {
        Task.Run(() => { });
    }

    for (int i = 0; i < ThreadCount; i++) {
        var t = new Thread(() => { });
        t.Start();
    }