Consider a process which is creating multiple application domains. Do these Application domains share same thread pool? If yes, how is it coordinated between multiple application domains?
Thread pools do not make sense when you need thread which perform entirely dissimilar and unrelated actions, which cannot be considered "jobs"; e.g., One thread for GUI event handling, another for backend processing. Thread pools also don't make sense when processing forms a pipeline.
Once a thread in the thread pool completes its task, it's returned to a queue of waiting threads. From this moment it can be reused. This reuse enables applications to avoid the cost of creating a new thread for each task. There is only one thread pool per process.
Thread pool in C# is a collection of threads. It is used to perform tasks in the background. When a thread completes a task, it is sent to the queue wherein all the waiting threads are present. This is done so that it can be reused.
ThreadPool will create maximum of 10 threads to process 10 requests at a time. After process completion of any single Thread, ThreadPool will internally allocate the 11th request to this Thread and will keep on doing the same to all the remaining requests.
The ThreadPool is shared across all appdomains - since that means threads might end up switching between appdomains (potentially often!) there's been perf work around that:
http://blogs.msdn.com/b/ericeil/archive/2009/04/23/clr-4-0-threadpool-improvements-part-1.aspx
[...] In fact, we violate this “rule” already: since .NET 3.5, the CLR thread pool has maintained separate FIFO queues for each AppDomain in the process, and an additional independent FIFO queue for “native” work items such as those queued by a host (ASP.net being the prime user of this feature). We round-robin between these work queues, allowing each to execute work for some time before moving on to the next.[...]
BTW, note that strictly speaking the ThreadPool isn't shared across the entire process anymore, since the v4 CLR allows loading side-by-side with V2, and each will have its own threadpool.
The threadpool is shared between all appdomains, as each threadpool thread is context-agnostic and the whole threadpool runtime profile is highly dependent on the hardware you are running on (# of procs, hyperthreading and such)
There is one thread pool per process. The thread pool has a default size of 25 threads per available processor. The number of threads in the thread pool can be changed using the SetMaxThreads method. Each thread uses the default stack size and runs at the default priority.
Source : http://msdn.microsoft.com/en-us/library/system.threading.threadpool.aspx
If I remember correctly, the CLR handles the threadpool threads internally and cleans the thread context before serving another work request.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With