.NET中辅助线程和I/O线程的简单描述 [英] Simple description of worker and I/O threads in .NET

问题描述

很难在.NET中找到工作线程和I/O线程的详细而简单的描述

It's very hard to find detailed but simple description of worker and I/O threads in .NET

我对这个主题有什么清楚的了解(但在技术上可能并不准确):

What's clear to me regarding this topic (but may not be technically precise):

• 工作线程是应使用CPU进行工作的线程；
• I/O线程(也称为完成端口线程")应使用设备驱动程序来执行其工作，并且实质上不执行任何操作"，仅监视非CPU操作的完成情况.

• Worker threads are threads that should employ CPU for their work;
• I/O threads (also called "completion port threads") should employ device drivers for their work and essentially "do nothing", only monitor the completion of non-CPU operations.

不清楚的地方:

• 尽管ThreadPool.GetAvailableThreads方法返回两种类型的可用线程数，但似乎没有公共API可以安排I/O线程的工作.您只能在.NET中手动创建工作线程?
• 似乎单个I/O线程可以监视多个I/O操作.是真的吗如果是这样，为什么默认情况下ThreadPool有这么多可用的I/O线程?
• 在某些文本中，我读到了由I/O线程执行I/O操作完成后触发的回调.是真的吗考虑到此回调是CPU操作，这不是工作线程的工作吗?
• 更具体地说-ASP.NET异步页面是否使用I/O线程?将I/O工作切换到单独的线程而不是增加工作线程的最大数量时，性能上的好处到底是什么?是因为单个I/O线程会监视多个操作吗?还是Windows在使用I/O线程时进行更有效的上下文切换?

推荐答案

.net/CLR中的工作线程"一词通常仅指代除应用程序执行某些工作"的主线程以外的任何线程.产生了线程. 工作"实际上可能意味着任何事情，包括等待一些I/O完成. ThreadPool保留了工作线程的缓存，因为创建线程非常昂贵.

The term 'worker thread' in .net/CLR typically just refers to any thread other than the Main thread that does some 'work' on behalf of the application that spawned the thread. 'Work' could really mean anything, including waiting for some I/O to complete. The ThreadPool keeps a cache of worker threads because threads are expensive to create.

.net/CLR中的术语"I/O线程"是指ThreadPool保留的线程，用于从重叠"的win32调用(也称为完成端口I/O")分派NativeOverlapped回调. CLR维护自己的I/O完成端口，并可以将任何句柄绑定到该端口(通过ThreadPool.BindHandle API).此处的示例: http://blogs.msdn.com/junfeng/archive/2008/12/01/threadpool-bindhandle.aspx .许多.net API在内部使用此机制来接收NativeOverlapped回调，尽管典型的.net开发人员永远不会直接使用它.

The term 'I/O thread' in .net/CLR refers to the threads the ThreadPool reserves in order to dispatch NativeOverlapped callbacks from "overlapped" win32 calls (also known as "completion port I/O"). The CLR maintains its own I/O completion port, and can bind any handle to it (via the ThreadPool.BindHandle API). Example here: http://blogs.msdn.com/junfeng/archive/2008/12/01/threadpool-bindhandle.aspx. Many .net APIs use this mechanism internally to receive NativeOverlapped callbacks, though the typical .net developer won't ever use it directly.

工作线程"和"I/O线程"之间实际上并没有技术上的区别-它们都是普通线程.但是CLR ThreadPool保留了每个池的单独池，只是为了避免对工作线程的高需求耗尽所有可用于分发本机I/O回调的线程，从而可能导致死锁. (想象一个使用全部250个工作线程的应用程序，其中每个线程都在等待某个I/O完成).

There is really no technical difference between 'worker thread' and 'I/O thread' -- they are both just normal threads. But the CLR ThreadPool keeps separate pools of each simply to avoid a situation where high demand on worker threads exhausts all the threads available to dispatch native I/O callbacks, potentially leading to deadlock. (Imagine an application using all 250 worker threads, where each one is waiting for some I/O to complete).

开发人员在处理I/O回调时确实需要注意一些事项，以确保将I/O线程返回到ThreadPool中-也就是说，I/O回调代码应完成以下工作:服务回调，然后将线程的控制权返回给CLR线程池.如果需要更多工作，则应在工作线程上安排该工作.否则，应用程序可能会劫持"用作普通工作线程的CLR保留I/O完成线程池，从而导致上述死锁情况.

The developer does need to take some care when handling an I/O callback in order to ensure that the I/O thread is returned to the ThreadPool -- that is, I/O callback code should do the minimum work required to service the callback and then return control of the thread to the CLR threadpool. If more work is required, that work should be scheduled on a worker thread. Otherwise, the application risks 'hijacking' the CLR's pool of reserved I/O completion threads for use as normal worker threads, leading to the deadlock situation described above.

一些很好的参考资料供进一步阅读: win32 I/O完成端口: http://msdn.microsoft .com/en-us/library/aa365198(VS.85).aspx 托管线程池: http://msdn.microsoft.com/en-us/library/0ka9477y.aspx BindHandle的示例: http://blogs.msdn.com /junfeng/archive/2008/12/01/threadpool-bindhandle.aspx

Some good references for further reading: win32 I/O completion ports: http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx managed threadpool: http://msdn.microsoft.com/en-us/library/0ka9477y.aspx example of BindHandle: http://blogs.msdn.com/junfeng/archive/2008/12/01/threadpool-bindhandle.aspx

这篇关于.NET中辅助线程和I/O线程的简单描述的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！