Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

.NET Threadpool worker threads and asynchronous IO threads

OK, as I understand it, the .NET Threadpool maintains a number of background threads ready to be used for tasks of some kind.

The Get/SetMinThreads and Get/SetMaxThreads methods contain two parameters that can be returned or adjusted.

According to MSDN the two parameters indicate the number of worker threads and the number of threads used for async IO operations.

What type of operations use these specific type of thread?

Worker threads:

  1. QueueUserWorkItem I presume.
  2. Anything else?

Async IO threads:

  1. Used when calling Beginxxx, Endxxx on file streams for example? (Or network, serial port, etc.)
  2. Anything else?

Thanks for any clarification, or a good link on the subject.

like image 895
Andy Avatar asked Jul 03 '10 20:07

Andy


People also ask

What is the difference between thread and ThreadPool?

A thread pool is - as the name suggests - a pool of worker threads which are always running. Those threads then normally take tasks from a list, execute them, then try to take the next task. If there's no task, the thread will wait.

Is ThreadPool async?

The thread-based asynchronous programming approach, also called “work-stealing” or “bulkheading”, allows one thread pool to hand over a task to another thread pool (let's call it a work thread pool) and be notified to handle the result when the worker thread pool is done with the task.

When should you not use ThreadPool?

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.

What is .NET ThreadPool?

ThreadPool class provides your application with a pool of worker threads that are managed by the system, allowing you to concentrate on application tasks rather than thread management.


1 Answers

Yes, QUWI but also a delegate type's BeginInvoke() method. And employed by a few classes, BackgroundWorker is the best known example. Which under the hood merely uses delegate's BeginInvoke().

I/O completion threads are a very low-level Windows feature to get code to run quickly when an I/O request completes. Most visible from the ReadFileEx() function's last argument, there are others. The managed equivalent is exposed through ThreadPool.BindHandle().

It is the job of .NET classes to get that right. Just a few use it: FileStream, PipeStream, FileSystemWatcher, Socket, SerialPort's internal worker thread and some WCF channel support classes.

I'm personally not a big fan of getting these config details exposed in the API, especially the I/O completion thread ones. It's a bit of a cop-out by the BCL team, some FUD on their end. These settings affect the entire program, the defaults are already quite generous. Tinkering with them is roughly equivalent to calling GC.Collect(). If you ever manage to find a good reason to change them, that better be when stuck in a hellhole with only one hour left to catch the plane back home. Been there :)

like image 79
Hans Passant Avatar answered Oct 10 '22 06:10

Hans Passant