.NET Threadpool工作线程和异步IO线程
好的，据我了解，.NET 线程池维护着许多后台线程，准备用于某种任务。
Get/SetMinThreads 和 Get/SetMaxThreads 方法包含两个可以返回或调整的参数。
根据 MSDN 这两个参数表示数量工作线程数和用于异步 IO 操作的线程数。
哪些类型的操作使用这些特定类型的线程？
工作线程：
- 我认为是 QueueUserWorkItem。
- 还要别的吗？
异步IO线程：
- 例如在文件流上调用Beginxxx、Endxxx时使用？ （或者网络、串口等）
- 还有其他吗？
感谢您的任何澄清或有关该主题的良好链接。
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:
- QueueUserWorkItem I presume.
- Anything else?
Async IO threads:
- Used when calling Beginxxx, Endxxx on file streams for example? (Or network, serial port, etc.)
- Anything else?
Thanks for any clarification, or a good link on the subject.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，QUWI 也是委托类型的 BeginInvoke() 方法。 BackgroundWorker 是最著名的例子，被几个类所使用。在幕后仅使用委托的 BeginInvoke()。
I/O 完成线程是一项非常低级的 Windows 功能，可让代码在 I/O 请求完成时快速运行。最明显的是 ReadFileEx() 函数的最后一个参数，还有其他参数。托管等效项通过 ThreadPool.BindHandle() 公开。
.NET 类的工作就是做到这一点。只有少数几个使用它：FileStream、PipeStream、FileSystemWatcher、Socket、SerialPort 的内部工作线程和一些 WCF 通道支持类。
我个人不太喜欢在 API 中公开这些配置详细信息，尤其是 I/O 完成线程的配置详细信息。 BCL 团队有点逃避责任，他们对此有些 FUD。这些设置影响整个程序，默认值已经相当慷慨了。修改它们大致相当于调用 GC.Collect()。如果你想找到一个很好的理由来改变它们，那最好是在你被困在地狱里，只剩下一个小时才能赶飞机回家的时候。去过那里:)
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 :)