IOCP关键部分设计答案

【问题标题】：IOCP Critical Section DesignIOCP关键部分设计
【发布时间】：2014-01-06 04:15:14
【问题描述】：

我正在运行一个完全可操作的 IOCP TCP 套接字应用程序。今天我在考虑关键部分的设计，现在我脑子里有一个没完没了的问题：全局还是每个客户的关键部分？我来到这里是因为我看到如果每个线程都依赖于一个锁，那么使用多个工作线程是没有意义的，对吧？我的意思是...现在我没有看到 100 个并发客户端有任何性能问题，但如果是 10000 个呢？

我的共享资源是每个客户端预分配的结构，因此，每个客户端都有自己的 IO 上下文、套接字和东西。没有客户端间资源共享，所以我认为这是使用每个客户端 CS 的另一点。我使用一个接受线程和 8 个（处理器 * 2）工作线程。此应用程序基本上是为小型（

【问题讨论】：

也许 - 答案取决于很多特定于您的问题和特定于您的设计的信息。

标签： c++ multithreading sockets iocp

【解决方案1】：

“正确”答案可能取决于您的设计、并发客户端的数量以及您对可用硬件的性能要求。

一般来说，我发现最好使用最简单的方法，然后进行分析以定位热点。

但是...您说您没有客户端间共享资源，所以我假设您需要做的唯一同步是围绕“每个连接”状态。

由于它是每个连接，因此（对我而言）显而易见的设计是每个连接状态包含其自己的关键部分。您认为这种方法的缺点是什么？

单个共享锁的问题是您在没有理由相互阻塞的连接（和线程）之间引入了争用。这将对性能产生不利影响，并可能随着连接数的增加而成为热点。

一旦您拥有每个连接锁，您可能希望通过让 IOCP 线程简单地锁定以将完成放置在每个连接队列中进行处理来尽可能避免使用它。这样做的好处是允许单个 IOCP 线程在每个连接上工作，并防止单个连接有额外的 IOCP 线程阻塞它。它也适用于“成功时跳过完成端口”处理。

【讨论】：

是的 - 我每个插槽都使用一个 CS。
其实我用的是单共享锁设计。我将代码更改为每个连接锁定，看看是否会有一些改进......
在我看来，如果单线程处理单连接，并且线程之间没有共享数据，则可以一起抛出CS。但如果它访问多个线程之间的某些共享数据，您可能需要放置特定于该数据的 CS。
你对article中关于锁定粒度的内容有什么看法？作者认为全局锁比每个套接字锁更高效。我对此感到困惑。
James，好吧，既然那篇文章的作者是我……很抱歉让你感到困惑。这篇文章写于 2002 年，当时硬件通常受到更多限制，操作系统也有很大不同——文章中的代码最初是在 NT4 上运行的。所以，正如我在上面的回答中所说的“这取决于设计”。在撰写本文时，有几台服务器为大量连接提供服务，最好为了资源使用而牺牲锁争用。现在这不太可能是必需的，我的代码甚至不再支持“共享”锁的概念。