Can someone list some comparison points between Thread Spawning vs Thread Pooling, which one is better?
+7
A:
A "pool" contains a list of available "threads" ready to be used whereas "spawning" refers to actually creating a new thread.
The usefulness of "Thread Pooling" lies in "lower time-to-use": creation time overhead is avoided.
In terms of "which one is better": it depends. If the creation-time overhead is a problem use Thread-pooling. This is a common problem in environments where lots of "short-lived tasks" need to be performed.
As pointed out by other folks, there is a "management overhead" for Thread-Pooling: this is minimal if properly implemented. E.g. limiting the number of threads in the pool is trivial.
jldupont
2010-01-12 15:17:14
is there a big difference( in terms of time consumption) in creating a new thread as compared to picking a task from a queue and allocating it to a thread from a pool, on windows xp OS?
reonze
2010-01-12 15:21:56
I haven't done any serious Windows programming in ages but I am pretty sure that picking an available thread from a list (simple operation) is far cheaper than spawning a new thread.
jldupont
2010-01-12 15:38:06
Spawning a new physical thread will mean a transition into Kernel mode and setting up a bunch of mernel structures, so the overhead will be higher. But as we all know you shouldn't optimize prematurely. If you only create one thread you're not going to notice the overhead, if you are creating thousands you probably will, but even that probably depends on the work the thread is doing which may swamp the time it takes to create the thread.
Kevin Jones
2010-01-12 16:39:41
A:
It depends on what you want to execute on the other thread.
For short task it is better to use a thread pool, for long task it may be better to spawn a new thread as it could starve the thread pool for other tasks.
SelflessCoder
2010-01-12 15:19:19
It is also nice for performance analysis and logging that you can rename a spawned thread and thus make it easy for performance analysis - if it is a threadpool it gets more difficult to guess which thread belongs to which task.
weismat
2010-01-12 15:33:30
+3
A:
For some definition of "better", you generally want to go with a thread pool. Without knowing what your use case is, consider that with a thread pool, you have a fixed number of threads which can all be created at startup or can be created on demand (but the number of threads cannot exceed the size of the pool). If a task is submitted and no thread is available, it is put into a queue until there is a thread free to handle it.
If you are spawning threads in response to requests or some other kind of trigger, you run the risk of depleting all your resources as there is nothing to cap the amount of threads created.
Another benefit to thread pooling is reuse - the same threads are used over and over to handle different tasks, rather than having to create a new thread each time.
As pointed out by others, if you have a small number of tasks that will run for a long time, this would negate the benefits gained by avoiding frequent thread creation (since you would not need to create a ton of threads anyway).
danben
2010-01-12 15:20:01
There is no reason why you couldn't cap the number of spawned threads.
Tony Edgecombe
2010-01-12 15:21:54
That's true, I didn't claim it was impossible. But then why not use a pool?
danben
2010-01-12 15:23:14
Well, unless 'generally' is a relatively long running task (anything over a few seconds is, really). (Ab)using the threadpool for long running operations could lead to nasty forms of deadlocks etc.
Wim Hollebrandse
2010-01-12 15:24:21
Creating new threads is a more expensive operation than one might expect. This makes it especially worthwhile if many very short tasks are being executed.
Thorarin
2010-01-12 15:24:26
+1 for pointing out that it's more about resource control than cost-to-spawn
kdgregory
2010-01-12 15:24:51
@Wim: what is *the* thread pool you are referring to? This is a language and platform agnostic question.
Thorarin
2010-01-12 15:27:04
Thorarin, yes so equally read it as such. Assuming the current platform/runtime has a built in threadpool seems reasonable, given OP's question.
Wim Hollebrandse
2010-01-12 15:31:16
@Wim: If I'm using .net Threadpool (limit of 100 threads) for thousands of tasks and some of them may take more than ten seconds, in this scenario can you tell us how a deadlock occurs? At some point of time thread pool will finish all the tasks as every thread will finish the task for sure (in my scenario). I'm not clear how deadlock occurs here. Can you clarify that some more?
JPReddy
2010-09-16 12:51:02
@JPReddy: It doesn't *just* happen. You'd have to have a scenario where you have dependencies; one of the threads waits for the result of another. If there are no threads available, deadlock could easily occur.
Wim Hollebrandse
2010-09-25 19:55:22
A:
The main difference is that a ThreadPool maintains a set of threads that are already spun-up and available for use, because starting a new thread can be expensive processor-wise.
Note however that even a ThreadPool needs to "spawn" threads... it usually depends on workload - if there is a lot of work to be done, a good threadpool will spin up new threads to handle the load based on configuration and system resources.
Michael Bray
2010-01-12 15:21:00
+1
A:
All depends on your scenario. Creating new threads is resource intensive and an expensive operation. Most very short asynchronous operations (less than a few seconds max) could make use of the thread pool.
For longer running operations that you want to run in the background, you'd typically create (spawn) your own thread. (Ab)using a platform/runtime built-in threadpool for long running operations could lead to nasty forms of deadlocks etc.
Wim Hollebrandse
2010-01-12 15:21:37
A:
There is little extra time required for creating/spawning thread, where as thread poll already contains created threads which are ready to be used.
Gopalakrishnan Subramani
2010-01-12 15:21:56
+1
A:
My feeling is that you should start just by creating a thread as needed... If the performance of this is OK, then you're done. If at some point, you detect that you need lower latency around thread creation you can generally drop in a thread pool without breaking anything...
dicroce
2010-01-12 15:26:31
+5
A:
Thread pool threads are much cheaper than a regular Thread, they pool the system resources required for threads. But they have a number of limitations that may make them unfit:
- You cannot abort a threadpool thread
- There is no easy way to detect that a threadpool completed, no Thread.Join()
- There is no easy way to marshal exceptions from a threadpool thread
- You cannot display any kind of UI on a threadpool thread beyond a message box
- A threadpool thread should not run longer than a few seconds
- A threadpool thread should not block for a long time
The latter two constraints are a side-effect of the threadpool scheduler, it tries to limit the number of active threads to the number of cores your CPU has available. This can cause long delays if you schedule many long running threads that block often.
The BackgroundWorker class has workarounds for the first 3 limitations but still uses a threadpool thread.
Hans Passant
2010-01-12 15:43:28