C++ 处理一个套接字和多个线程时异步IO的用例

我很难理解为什么一些程序员在只有一个套接字的情况下推荐异步IO，就像UDP的常见情况一样。这是针对ASIO的，ASIO是我们将在C++17中获得的基础，但通常适用于任何异步库

是否有一个有意义的用例？我看不出性能如何会比两个线程更好，一个线程在读取时阻塞（然后将数据包排入线程池），另一个线程在写入时阻塞，条件变量等待数据包发送。最好在那里使用多包函数，以避免操作系统开销

ASIO中的UDP或单套接字TCP是否有助于提高效率？几乎所有ASIO示例都显示同步读写。即您只需在处理程序中对最后一个进行另一次读取或写入。因此，每个套接字获得的好处很少，如果只处理一个套接字，那么对于这些示例来说，没有什么比专用的recv和write线程更好的了

---

我是不是遗漏了什么

一般来说，ASIO可能会产生比多线程更差的性能。有了真正的多线程和多核（如今的标准），您将有机会同时为两个客户机提供服务（单线程ASIO模型永远不会出现这种情况）。但是，例如，如果您的任务是IO绑定的，使用具有同步访问的公共资源（例如，单线程DB）或受到任何其他锁的约束，则多线程的任何好处都将消失

---

另一方面，ASIO模型更简单，不需要任何同步，允许以单线程模式编译程序（因此，例如，提高内存分配的性能，消除对原子访问的需求等）。在许多情况下，这些好处大于缺点。

不幸的是，许多ASIO实现都有umm.'问题'。在不允许多个IO请求在内核中排队的情况下，进行比简单的阻塞设计更多的系统调用是其中之一：（这其实很有趣，阅读一些问题，比如“我使用非阻塞ASIO实现高性能，我如何等待结果？”我看到一些人说可以对多个读或写进行排队，但这取决于操作系统，其中一些甚至返回的比你想要的少，这使得使用几乎毫无意义（奇怪的交织数据包）。在一个线程进行读写的情况下，这种情况是永远不会发生的。无论哪种情况，我都看不出单插槽的速度会比我描述的情况更快。从我个人的经验来看，很少有使用案例：单核小尺寸，上下文切换成本高；内存受限的环境，非常适合处理flow网络堆栈中的控制，而不是应用程序；延迟不重要的协议，多线程复杂性不会超过潜在收益。Asio是为其设计的。作为其设计的结果，我承认在特定场景中会牺牲一些性能。“Asio模型更简单”这不一定是真的，因为正常的顺序代码被转换成回调。控制流被转换成回调非常糟糕。@usr，simpler是主观的。我发现它更简单：），但可能是因为我对它有很长的经验。与奇怪的ASIO调用集群相比，单线程读写代码要少得多，读起来更干净，而且性能更高。我不介意ASIO（或IOCP/任何东西）的额外复杂性如果您只需编写一次，它就可以工作，并且在每个操作系统上使用最快的方法，则会添加。在许多情况下，ASIO似乎没有使用最快的方法，在某些情况下，它非常未优化。感觉它是为处理HTTP服务器而编写的，而其他所有内容都是在最后附加的。特别是UDP似乎处理得不好“我不明白你说它不需要同步是什么意思。如果你使用多个线程和多个套接字，你就需要。我不确定现在编写软件的任何人都应该使用单个线程，除非他们在嵌入式系统上。你可以利用每一个机会让你r应用程序感觉更平滑，可扩展性更好，尤其是当它的工作量几乎相同时，只有我的2美分。@RylerSturden，有一些成功的单线程系统。当然有它们的用法。NodeJs就是其中之一。