C++ IOCP临界截面设计

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

我的共享资源是每个客户机预先分配的结构，因此，每个客户机都有自己的IO上下文、套接字和其他内容。没有客户端间的资源共享，所以我认为这是使用每客户端CS的另一个要点。我使用一个接受线程和8个（处理器*2）工作线程。此应用程序基本上是为小型（<1KB）数据包设计的，但有时也用于文件流。

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

总的来说，我发现最好使用最简单的方法，然后配置文件来定位热点

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

因为它是每个连接，所以（对我来说）显而易见的设计是每个连接状态包含它自己的临界部分。你认为这种方法的缺点是什么

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

---

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

可能-答案取决于许多特定于您的问题和设计的信息。是的-我使用CS每个套接字。实际上，我使用单一共享锁设计。我会将代码更改为每连接锁，看看是否会有一些改进…在我看来，如果单线程处理单连接，并且线程之间没有共享数据，那么可以将CS全部抛出。但是，如果它在多个线程之间访问某些共享数据，您可能希望将CS放置在该数据的特定位置。您如何看待该线程中有关锁定粒度的内容？作者认为全局锁比每个套接字锁性能更好。我对此感到困惑。詹姆斯，好吧，既然那篇文章的作者是我。。。很抱歉把你弄糊涂了。这篇文章是在2002年写的，当时的硬件往往更为有限，操作系统也有很大不同——文章中的代码最初是在NT4上运行的。因此，正如我在上面的回答中所说，“这取决于设计”。在撰写本文时，有几个服务器为大量连接提供服务，在这些服务器中，最好牺牲锁争用来使用资源。现在这不太可能是必需的，我的代码甚至不再支持“共享”锁的概念。