Thread vs ThreadPool

What is the difference between using a new thread and using a thread from the thread pool? What performance benefits are there and why should I consider using a thread from the pool rather than one I've explicitly created? I'm thinking specifically of .NET here, but general examples are fine.

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.

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.

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();
	}

Check here for an earlier thread:

https://stackoverflow.com/questions/10274/when-should-i-not-use-the-threadpool-in-net

Summary is that Threadpool is good if you need to spawn many shortlived threads, whereas using Threads gives you a bit more control.

If you need a lot of threads, you probably want to use a ThreadPool. They re-use threads saving you the overhead of thread creation.

If you just need one thread to get something done, Thread is probably easiest.

Thread local storage is not a good idea with thread pools. It gives threads an "identity"; not all threads are equal anymore. Now thread pools are especially useful if you just need a bunch of identical threads, ready to do your work without creation overhead.

The primary need for theadpool threads is to handle short little tasks that are expected to complete almost instantly. Hardware interrupt handlers often run in a stacking context which would not be suitable for non-kernel code, but a hardware interrupt handler may discover that a user-mode I/O completion callback should be run as soon as possible. Creating a new thread for the purpose of running such a thing would be massive overkill. Having a few pre-created threads which can be dispatched to run I/O completion callbacks or other similar things is much more efficient.

A key aspect of such threads is that if I/O completion methods always complete essentially instantaneously and never block, and the number of such threads that are presently running such methods is at least equal to the number of processors, the only way any other thread could run before one of the aforementioned methods finishes would be if one of the other methods blocks or its execution time exceeds a normal threading time-slice; neither of those should happen very often if the thread pool is used as intended.

If a method cannot be expected to exit within 100ms or so of when it starts execution, the method should be executed via some means other than the main thread pool. If one has a lot of tasks to perform which are CPU intensive but won't block, it may be helpful to dispatch them using a pool of application threads (one per CPU core) which is separate from the "main" threadpool, since using more threads than cores will be counterproductive when running non-blocking CPU-intensive tasks. If, however, a method will take a second or longer to execute, and will spend most of its time blocked, the method should likely be run in a dedicated thread, and should almost certainly not be run in a main-threadpool thread. If a long-running operation needs to be triggered by something like an I/O callback, one should either start a thread for the long-running operation in advance of the callback and have it wait on a monitor which the callback pulses, or else have the callback launch a new thread to perform the operation while the callback exits, effectively returning its own thread to the threadpool.

In general (I have never used .NET), a thread pool would be used for resource management purposes. It allows constraints to be configured into your software. It also may be done for performance reasons, as creation of new threads may be costly.

There may also be system specific reasons. In Java (again I don't know if this applies to .NET), the manager of the threads may apply thread specific variables as each thread is pulled from the pool, and unset them when they are returned (common way to pass something like an identity).

Example constraint: I only have 10 db connections, so I would only allow 10 worker threads for accessing the database.

This doesn't mean that you should not create your own threads, but there are conditions under which it makes sense to use a pool.

Thread:

1. Creating a Thread is far slower than using Thread-pool.
2. You can change the priority of a thread.
3. The max number of threads in a process related to resources.
4. Thread is at the OS level and controlled by OS.
5. Using Thread is a better option when the task is relatively long-running

Thread-Pool:

1. Running a Thread on thread-pool is far faster than directly creating a Thread.
2. You can not change the priority of a thread run based on Thread-pool.
3. There is only one Thread-pool per process.
4. The Thread-pool is managed by CLR.
5. The Thread-pool is useful for short-lived operation.
6. The numbers of Threads in Thread-pool is related to the application load.
7. TPL tasks run based on Thread-pool

Using a pool is a good idea, if you don't know or can't control how many thread will be created.

Just have an issue with a form using thread to update some field from a database on a positionchanged event of a list control (avoid freeze). It took 5 minutes for my user to have an error from the database (too many connection with Access) because he was changing the list position too fast...

I know there are other ways to resolve the base problem (including not using access) but pooling is a good start.