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:
Async IO threads:
Thanks for any clarification, or a good link on the subject.
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.
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.
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.
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.
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 :)
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