views:

60

answers:

3

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?

A: 

Not 100% sure, but I think thread pool is once per process, not once per AppDomain. Try look at this article on thread & appdomain :

Andrea Parodi
+2  A: 

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.

Florian Doyon
This is the link to the latest documentation for .NET 4. http://msdn.microsoft.com/en-us/library/system.threading.threadpool.aspx. There is 250 worker threads per available processor.
btlog
+3  A: 

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.

James Manning