关于ACE_WIN32_Proactor代码的一些疑惑

wishel

我们的观点是矛盾的。
他问的是是不是 一定 要多线程跑event loop
我的意思是，不要，尽量不要，虽然也可以多线程跑，但没必要。（我的观点是性能不好，但这点还没说）
你的意思是windows下最好（或者必须）多线程跑event loop，因为性能好。我理解的对么？

wishel

我windows下用的不多，呼唤winston老大也进来说两句哈。

modern

嗯，一般是使用多线程运行proactor事件循环的。
简单的原理可以参考下面的帖子，详细原因windows网络编程中有详细的介绍。
http://www.acejoy.com/bbs/viewth ... &extra=page%3D1

modern

关于这事，我请教过winston老大，我之前也一直不理解原因，
对这个CPU数目的2n+2，一直想不明白。
后来按老大的意思，找到我提到的章节，反复看了几遍，终于明白了。

wishel

呵呵，那个帖子我看过，windows网络编程那一章我也看过。这都是具体实现细节。

我的观点是，如果每个线程跑一个event loop，这样性能差。
多线程引入了切换和管理开销，所以总体性能会下降。
因为用的异步io，不存在阻塞，所以单线程处理性能最好。

还是一个观念问题，多线程不总是比单线程性能好，什么时候好呢？
不多说了，请winston老大来答疑解惑:lol

winston

在windows平台，和linux有很大差异。
完成端口，一般都是配合线程池来运行的。怎么配置线程池中的线程数量呢？按比较权威的说法，是CPU数目X2。
API里面，也有这个说明，
HANDLE CreateIoCompletionPort(
  HANDLE FileHandle,
  HANDLE ExistingCompletionPort,
  ULONG_PTR CompletionKey,
  DWORD NumberOfConcurrentThreads
);

NumberOfConcurrentThreads
[in] Maximum number of threads that the operating system can allow to concurrently process I/O completion packets for the I/O completion port. This parameter is ignored if the ExistingCompletionPort parameter is not NULL.
If this parameter is zero, the system allows as many concurrently running threads as there are processors in the system.

CPU X 2是一本书籍上面的建议和经验值，可自行测试决定。道理是因为某些线程操作会阻塞后续处理，所以要增加一些。


但是Proactor的事件处理循环，里面不牵扯到线程池的问题。这是有意的设计，而不是缺陷。这种设计更加灵活，也更加让人难以理解了。如果只在一个线程中运行Proactor循环，在多核、多CPU的系统上面，无法发挥完成端口全部的能力。所以要在多个线程中运行Proactor循环。

modern

多线程使用不恰当的确会引起切换与管理的开销，最终导致总体性能下降，
因此，人家推荐了启动多线程数量的一个经验值，也是避免扩大化你所提到线程切换的问题。
凡事有所得必有所失，关键在于一个权衡，看哪边的付出代价更小。
咱们这里不讨论多线程与单线程的孰优孰劣，这个问题远了。

下面是我引用书上的一个例子，可以预见在这种情况下，性能是会有提升。
对单I / O操作数据来说，它最大的一个优点便是允许我们在同一个句柄上，同时管理多个I / O操作（读／
写，多个读，多个写，等等）。大家此时或许会产生这样的疑问：在同一个套接字上，真的有
必要同时投递多个I / O操作吗？答案在于系统的“伸缩性”，或者说“扩展能力”。例如，假定
我们的机器安装了多个中央处理器，每个处理器都在运行一个工作者线程，那么在同一个时
候，完全可能有几个不同的处理器在同一个套接字上，进行数据的收发操作。

wishel

好，谢谢winton老大解释。
我回去思考下，明天回复。

winston

我们的这些探讨，对ACE的初学者是最有帮助的，不然理解起来，要花费很多很多功夫。

modern

最近有点职业病，我刚在思考一个问题，如何通过测试数据来说明这个问题。
思考之后，我认为如果要得出这个值可能受限于很多实际应用情况。

换言之，可能即便在这一步，使用多线程运行proactor性能被提升了，
系统的整体处理性能也可能由于其他的各种原因被拉下来。
比如在实际事务处理线程池处，由于处理过慢，造成产生了排队阻塞。

或者应用场景或者系统的应用规模决定了，不会产生触及该瓶颈，
单线程运行proactor的性能已经够用了。
比如，某采集设备，连接较少，但是数据量很大，
应用协议出于某种目的封的数据包较大。

所以抛开具体应用场景单独测试该值也是没有意义的。