0

This answer (https://stackoverflow.com/a/6000891/197229) provides interesting information on the modern .Net thread pool (https://learn.microsoft.com/en-us/dotnet/api/system.threading.threadpool?view=netcore-3.1)

Beginning with the .NET Framework 4, the default size of the thread pool for a process depends on several factors, such as the size of the virtual address space. A process can call the GetMaxThreads method to determine the number of threads. The number of threads in the thread pool can be changed by using the SetMaxThreads method. Each thread uses the default stack size and runs at the default priority.

My application is expected to run on an app-server with several other applications. Does .Net treat each application entirely separately when auto-allocating the threadpool size, and if not should I? My thought was if 10 processes each have a threadpool of 25, that's a lot of threads?

Mr. Boy
  • 60,845
  • 93
  • 320
  • 589
  • Is your question specific to .NET Framework 4 or are you also considering (ASP).NET Core or the latest .NET Framework 4.8? – dymanoid Jun 08 '20 at 14:07
  • @dymanoid 4.0 and newer - since the threadpool changed in 4. Not sure how to express this adequately in tags! – Mr. Boy Jun 08 '20 at 14:08
  • 1
    I'd remove the `.net-4.0` tag probably: "Use for questions specifically related to .NET Framework 4.0". – dymanoid Jun 08 '20 at 14:09

1 Answers1

1

My thought was if 10 processes each have a threadpool of 25

That's correct, each application has its own managed thread pool.

that's a lot of threads?

Not really, a typical system will have thousands of threads at any point in time, and most of them will be sleeping. Sleeping threads use no resources besides consideration for waking up (timers, socket selects, coarse synchronization like mutexes, etc).

Blindy
  • 65,249
  • 10
  • 91
  • 131
  • To give you an example, one piece of software that I developed to monitor a flight simulator's systems in real time has 124 threads at every point in time, and overall I've never seen it take more than 2.5% of the CPU. It's generally better to have the thread allocated and ready to go than to find yourself needing to start up a thread. – Blindy Jun 08 '20 at 14:11
  • Sounds like "let it do what it wants" is the best advice in 99% of cases then! – Mr. Boy Jun 08 '20 at 14:15
  • On the contrary, in any moderately complex application you'll want multiple thread pools to run your tasks. CPU bound operations (like image resize) should not starve the I/O bound operations (downloading the image to resize in the first place), so you queue each task on another pool. – Blindy Jun 08 '20 at 14:17
  • My point was simply to not be afraid of threads, pre-allocated threads are like spiders, friends! – Blindy Jun 08 '20 at 14:18
  • @Blindy _a flight simulator's systems in real time has 124 threads at every point in time, and overall I've never seen it take more than 2.5%_: what the point of such amount of threads if they aren't used to the fullest? – cassandrad Jun 08 '20 at 14:39
  • They're all waiting on blocking socket calls, processing a small data buffer, forwarding the processed data to the proper systems and then going back to waiting. Keeps the code clean and blocking socket I/O is very efficiently implemented in Windows. – Blindy Jun 08 '20 at 14:41