Given an ASMX service application hosted on Windows server 2008r2, IIS 7.5, integrated pool, .net 4.0 CLR, 64-bit. It is almost asynchronous and widely use TPL library.
Is it correct to assume that .NET thread-pool minimum worker threads configured to be N forces N worker threads creation at start-up?
I'm expecting this behavior but it does not happen or happens intermittently.
Here are details on configuration: Machine.config section has its attribute 'minWorkerThreads' set to 100, in order to init thread-pool with minimum 100*CPUcount (let's say 400 for 4 core desktop) worker threads.
Just after service application start ThreadPool.GetMinThreads(out minWorkerThreadsCount, out minIoThreadsCount) shows as expected that minWorkerThreadsCount is 400.
Despite this fact Debug 'Threads' window shows only 60 threads the same as Task manager. It seems like thread-pool falls back to the default behavior, but minWorkerThreadsCount is still 400.
Any ideas of what can trigger such behavior or decrease the number of threads at run-time? Allegedly this issue appears when application was build in .NET 4.5 run-time targeting .NET 4.0.
I would appreciate any input.
No. It will grow quickly up to that number rather than start with that many threads.
See part of ThreadPool.SetMinThreads I highligted:
Sets the minimum number of threads the thread pool creates on demand, as new requests are made, before switching to an algorithm for managing thread creation and destruction.
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