IOCP 线程 - 澄清？

Posted 2023-02-19

【中文标题】IOCP 线程 - 澄清？

【英文标题】：IOCP threads - Clarification?

【发布时间】：2015-04-25 18:46:04

【问题描述】：

在阅读this article 后指出：

设备完成其工作后，（IO操作）-它通知CPU 通过中断。

... ... ...

但是，只有“完成”状态 存在于操作系统级别；进程有自己的内存空间，必须 得到通知

... ... ...

由于库/BCL 使用标准 P/Invoke 重叠的 I/O 系统，它已经注册了句柄 I/O 完成端口 (IOCP)，它是线程池的一部分。

... ... ...

所以短暂借用了一个I/O线程池线程来执行APC， 通知任务完成。

我对粗体部分很感兴趣：

如果我理解正确的话，IO操作完成后，它必须通知执行IO操作的实际进程。

问题 #1：

这是否意味着它为每个完成的 IO 操作抓取一个 new 线程池线程 ？或者它是专用的线程数？

问题 #2：

正在看：

for (int i=0;i<1000;i++)
    
      PingAsync_NOT_AWAITED(i); //notice not awaited !
    

这是否意味着我将有 1000 个 IOCP 线程池线程同时（有点）在这里运行，当所有线程都完成时？

【问题讨论】：

Royi，你可以看看我的小实验here。

@Noseratio 谢谢！我一定会去看的。

您可能还想阅读这篇文章，以了解它在操作系统级别上的工作原理：I/O Completion Ports。

【参考方案1】：

这有点笼统，所以让我简单地说一下要点：

IOCP 线程位于单独的线程池中，可以这么说 - 这就是 I/O 线程设置。因此它们不会与用户线程池线程发生冲突（就像您在正常的 await 操作或 ThreadPool.QueueWorkerItem 中使用的线程一样）。

就像正常的线程池一样，它只会随着时间的推移缓慢地分配新线程。因此，即使同时出现异步响应的峰值，您也不会有 1000 个 I/O 线程。

在一个适当的异步应用程序中，您不会拥有比工作线程更多的核心数量，无论是给予还是索取。那是因为你要么在做大量的 CPU 工作并且你应该把它发布到一个普通的工作线程上，要么你在做 I/O 工作，你应该把它作为一个异步操作来做。

这个想法是您在 I/O 回调中花费的时间很少 - 您不会阻塞，也不会做大量的 CPU 工作。如果您违反了这一点（例如，将 Thread.Sleep(10000) 添加到您的回调中），那么是的，随着时间的推移，.NET 会创建大量的 IO 线程——但这只是不恰当的使用。

现在，I/O 线程与普通 CPU 线程有何不同？它们几乎相同，它们只是等待不同的信号 - 两者都是（简化警报）只是一个 while 循环，该循环在一个新工作项被应用程序的其他部分（或操作系统）。主要区别在于 I/O 线程使用 IOCP 队列（操作系统管理），而普通工作线程有自己的队列，完全由 .NET 管理并由应用程序程序员访问。

附带说明，不要忘记您的请求可能已同步完成。也许您正在一个while 循环中从TCP 流中读取，一次读取512 个字节。如果套接字缓冲区中有足够的数据，则多个ReadAsyncs 可以立即返回，而无需进行任何线程切换。这通常不是问题，因为 I/O 往往是您在典型应用程序中执行的最耗时的工作，因此不必等待 I/O 通常就可以了。但是，取决于异步发生的某些部分的错误代码（即使不能保证）很容易破坏您的应用程序。

【讨论】：

有一个分离但是两种类型的线程都在同一个ThreadPool中。您可以使用相同的方法设置您想要的数量：ThreadPoo.SetMaxThreads(int workerThreads, int completionPortThreads)

@i3arnon ThreadPool 不是游泳池。它只是静态类中的一堆方法。有单独的工作队列和线程池，其中一些由操作系统管理，一些由 CLR 本机代码管理，一些由托管 CLR 代码管理......这有点复杂。您通过ThreadPool 类与所有这些交互，但它们甚至没有相同的接口（例如BindHandle 与QueueUserWorkItem）。现在尝试挖掘 CLR 代码，因为它是公开的，它对多线程和异步代码有很多有趣和有趣的见解。

嗯，我想这取决于你想如何定义线程池。我会继续使用 MSDN 的 “线程池按需提供新的工作线程或 I/O 完成线程，直到达到每个类别的最小值。当达到最小值时，线程池可以在该类别中创建额外的线程或等到一些任务完成”

@i3arnon “该类别中的其他线程”本身意味着存在不同的池 :) 但这实际上只是在命名。只要您了解有两个单独的线程池（worker vs. I/O），这只是命名上的混淆。

【参考方案2】：

是不是意味着它为每个线程抓取了一个new线程池线程 完成 IO 操作 ?或者它是一个专用的线程数 这个？

为每个 I/O 请求创建一个新线程会非常低效，以至于无法达到目的。相反，运行时从少量线程开始（具体数量取决于您的环境），并根据需要添加和删除工作线程（具体算法同样因您的环境而异）。 .NET 的主要版本在此实现中都发生了变化，但基本思想保持不变：运行时尽最大努力创建和维护尽可能多的线程，以有效地为所有 I/O 提供服务。在我的系统（Windows 8.1、.NET 4.5.2）上，一个全新的控制台应用程序在输入 Main 时只有 3 个线程，并且在请求实际工作之前，这个数字不会增加。

这是否意味着我将同时拥有 1000 个 IOCP 线程池线程 （有点）跑这里，什么时候都完成了？

没有。当您发出 I/O 请求时，线程将在完成端口上等待以获取结果并调用注册的任何回调来处理结果（无论是通过 BeginXXX 方法还是作为任务的继续）。如果你使用了一个任务并且不等待它，那么该任务就简单地结束，线程返回到线程池中。

如果你真的等待它呢？ 1000 个 I/O 请求的结果不会真正同时到达，因为中断不会同时到达，但是假设间隔比我们需要处理它们的时间短得多。在这种情况下，线程池将继续旋转线程来处理结果，直到达到最大值，并且任何进一步的请求最终都将在完成端口上排队。根据您的配置方式，这些线程可能需要一些时间才能启动。

考虑以下（故意很糟糕的）玩具程序：

static void Main(string[] args) 
    printThreadCounts();
    var buffer = new byte[1024];
    const int requestCount = 30;
    int pendingRequestCount = requestCount;
    for (int i = 0; i != requestCount; ++i) 
        var stream = new FileStream(
            @"C:\Windows\win.ini",
            FileMode.Open, FileAccess.Read, FileShare.ReadWrite, 
            buffer.Length, FileOptions.Asynchronous
        );
        stream.BeginRead(
            buffer, 0, buffer.Length,
            delegate 
                Interlocked.Decrement(ref pendingRequestCount);
                Thread.Sleep(Timeout.Infinite);
            , null
        );
    
    do 
        printThreadCounts();
        Thread.Sleep(1000);
     while (Thread.VolatileRead(ref pendingRequestCount) != 0);
    Console.WriteLine(new String('=', 40));
    printThreadCounts();


private static void printThreadCounts() 
    int completionPortThreads, maxCompletionPortThreads;
    int workerThreads, maxWorkerThreads;
    ThreadPool.GetMaxThreads(out maxWorkerThreads, out maxCompletionPortThreads);
    ThreadPool.GetAvailableThreads(out workerThreads, out completionPortThreads);
    Console.WriteLine(
        "Worker threads: 0, Completion port threads: 1, Total threads: 2", 
        maxWorkerThreads - workerThreads, 
        maxCompletionPortThreads - completionPortThreads, 
        Process.GetCurrentProcess().Threads.Count
    );

在我的系统（有 8 个逻辑处理器）上，输出如下（结果可能因您的系统而异）：

Worker threads: 0, Completion port threads: 0, Total threads: 3
Worker threads: 0, Completion port threads: 8, Total threads: 12
Worker threads: 0, Completion port threads: 9, Total threads: 13
Worker threads: 0, Completion port threads: 11, Total threads: 15
Worker threads: 0, Completion port threads: 13, Total threads: 17
Worker threads: 0, Completion port threads: 15, Total threads: 19
Worker threads: 0, Completion port threads: 17, Total threads: 21
Worker threads: 0, Completion port threads: 19, Total threads: 23
Worker threads: 0, Completion port threads: 21, Total threads: 25
Worker threads: 0, Completion port threads: 23, Total threads: 27
Worker threads: 0, Completion port threads: 25, Total threads: 29
Worker threads: 0, Completion port threads: 27, Total threads: 31
Worker threads: 0, Completion port threads: 29, Total threads: 33
========================================
Worker threads: 0, Completion port threads: 30, Total threads: 34

当我们发出 30 个异步请求时，线程池很快就会使 8 个线程可用于处理结果，但之后它只会以每秒 2 个左右的悠闲速度启动新线程。这表明，如果您想正确利用系统资源，最好确保您的 I/O 处理快速完成。实际上，让我们将委托更改为以下内容，这表示对请求的“正确”处理：

stream.BeginRead(
    buffer, 0, buffer.Length,
    ar => 
        stream.EndRead(ar);
        Interlocked.Decrement(ref pendingRequestCount);
    , null
);

结果：

Worker threads: 0, Completion port threads: 0, Total threads: 3
Worker threads: 0, Completion port threads: 1, Total threads: 11
========================================
Worker threads: 0, Completion port threads: 0, Total threads: 11

同样，结果可能会因您的系统和不同的运行而有所不同。在这里，我们几乎看不到完成端口线程的运行，而我们发出的 30 个请求在没有启动新线程的情况下完成。您应该会发现您可以将“30”更改为“100”甚至“100000”：我们的循环启动请求的速度不能超过完成请求的速度。但是请注意，结果严重偏向于我们，因为“I/O”一遍又一遍地读取相同的字节，并且将从操作系统缓存而不是从磁盘读取来提供服务。这并不是为了展示实际的吞吐量，当然，只是为了展示开销的差异。

要使用工作线程而不是完成端口线程重复这些结果，只需将FileOptions.Asynchronous 更改为FileOptions.None。这使得文件访问同步，异步操作将在工作线程上完成，而不是使用完成端口：

Worker threads: 0, Completion port threads: 0, Total threads: 3
Worker threads: 8, Completion port threads: 0, Total threads: 15
Worker threads: 9, Completion port threads: 0, Total threads: 16
Worker threads: 10, Completion port threads: 0, Total threads: 17
Worker threads: 11, Completion port threads: 0, Total threads: 18
Worker threads: 12, Completion port threads: 0, Total threads: 19
Worker threads: 13, Completion port threads: 0, Total threads: 20
Worker threads: 14, Completion port threads: 0, Total threads: 21
Worker threads: 15, Completion port threads: 0, Total threads: 22
Worker threads: 16, Completion port threads: 0, Total threads: 23
Worker threads: 17, Completion port threads: 0, Total threads: 24
Worker threads: 18, Completion port threads: 0, Total threads: 25
Worker threads: 19, Completion port threads: 0, Total threads: 26
Worker threads: 20, Completion port threads: 0, Total threads: 27
Worker threads: 21, Completion port threads: 0, Total threads: 28
Worker threads: 22, Completion port threads: 0, Total threads: 29
Worker threads: 23, Completion port threads: 0, Total threads: 30
Worker threads: 24, Completion port threads: 0, Total threads: 31
Worker threads: 25, Completion port threads: 0, Total threads: 32
Worker threads: 26, Completion port threads: 0, Total threads: 33
Worker threads: 27, Completion port threads: 0, Total threads: 34
Worker threads: 28, Completion port threads: 0, Total threads: 35
Worker threads: 29, Completion port threads: 0, Total threads: 36
========================================
Worker threads: 30, Completion port threads: 0, Total threads: 37

线程池每秒启动一个工作线程，而不是为完成端口线程启动的两个。显然，这些数字取决于实现，并且可能会在新版本中发生变化。

最后，让我们演示一下ThreadPool.SetMinThreads 的用法，以确保可用于完成请求的最少线程数。如果我们回到FileOptions.Asynchronous 并将ThreadPool.SetMinThreads(50, 50) 添加到我们玩具程序的Main 中，结果是：

Worker threads: 0, Completion port threads: 0, Total threads: 3
Worker threads: 0, Completion port threads: 31, Total threads: 35
========================================
Worker threads: 0, Completion port threads: 30, Total threads: 35

现在，线程池不再耐心地每两秒添加一个线程，而是继续旋转线程直到达到最大值（在这种情况下不会发生，因此最终计数保持在 30）。当然，所有这 30 个线程都陷入了无限等待——但如果这是一个真实的系统，那么这 30 个线程现在可能会做有用​​的工作，即使不是非常有效的工作。不过，我不会尝试 this 处理 100000 个请求。

【参考方案3】：

这是否意味着我将同时拥有 1000 个 IOCP 线程池线程 （有点）跑这里，什么时候都完成了？

不，一点也不。与ThreadPool 中可用的工作线程一样，我们也有“完成端口线程”。

这些线程专用于异步 I/O。不会预先创建线程。它们与工作线程一样按需创建。当线程池决定时，它们最终将被销毁。

借用一下作者的意思是，为了向进程通知 IO 的完成，使用了来自“完成端口线程”（ThreadPool）的一些任意线程。它不会执行任何冗长的操作，而是完成 IO 通知。

【讨论】：

（有点相关）如果我从一个站点下载了一个 html，并且它已经完成，并且尚未从应用程序中读取（但确实通知了），那么这些数据存储在哪里？跨度>

@RoyiNamir 它在某处的某个缓冲区中。有很多层缓冲，所以很难说具体在哪里。但是，当您收到通知时，它必须在 your 缓冲区中 - 当然，如果您使用 HttpClient 之类的东西，这是他的缓冲区，而如果您正在使用例如TcpClient 直接，它是你在做ReceiveAsync 时给它的byte[] 缓冲区。当然，这是您希望使用最高可用抽象的原因之一 - 网络（以及任何异步）很难，让聪明的人处理最困难的部分：D

【参考方案4】：

正如我们之前所说，IOCP 和工作线程在线程池中具有单独的资源。

无论您是否await IO 操作，都会发生向IOCP 或重叠IO 的注册。 await 是更高级别的机制，与那些 IOCP 的注册无关。

通过一个简单的测试，你可以看到虽然没有出现await，但应用程序仍在使用IOCP：

private static void Main(string[] args)

    Task.Run(() =>
    
        int count = 0;
        while (count < 30)
        
            int _;
            int iocpThreads;
            ThreadPool.GetAvailableThreads(out _, out iocpThreads);
            Console.WriteLine("Current number of IOCP threads availiable: 0", iocpThreads);
            count++;
            Thread.Sleep(10);
        
    );

    for (int i = 0; i < 30; i++)
    
        GetUrl(@"http://www.ynet.co.il");
    

    Console.ReadKey();


private static async Task<string> GetUrl(string url)

    var httpClient = new HttpClient();
    var response = await httpClient.GetAsync(url);
    return await response.Content.ReadAsStringAsync();

根据执行每个请求所需的时间量，您会在发出请求时看到 IOCP 缩小。您尝试创建的并发请求越多，可用的线程就越少。

【讨论】：

我会更改连接限制，因为您在这里被限制为 ~4 个连接....System.Net.ServicePointManager.DefaultConnectionLimit = 1000（恕我直言）

是否为 4 并不重要。关键是要看到这些 IOCP 真正投入使用，而您没有 await 任何请求。

哦，只是想指出它以查看更准确的结果 :-) - 对于其他可能想知道原因的人......

谁将您限制为 ~4 个连接？

***.com/questions/866350/…