如何为Begin/Async调用(如套接字IO)管理线程
本文关键字：套接字 IO 线程 管理 调用 Begin Async | 更新日期: 2023-09-27 18:08:46
. net Socket异步API在使用BeginXXX方法时自动管理线程。例如，如果我有100个活动连接发送和接收TCP消息，将使用大约3个线程。这让我很好奇。
- API是如何管理这个线程的?
- 所有的连接流是如何在要处理的线程之间分配的?
- 管理员如何优先处理哪些连接/读取/写入必须首先处理?
我的问题可能没有意义，因为我不知道它是如何工作的，具体要问什么，所以抱歉。基本上我需要知道这整个过程是如何在低层次上工作的
.Net Socket异步API在使用BeginXXX方法。
这并不完全正确。APM Begin/End风格的套接字API根本不管理线程。相反，完成AsyncCallback是在一个随机线程上调用的，该线程是异步套接字I/O操作完成的线程。最有可能的是，这将是一个IOCP池线程(I/O完成端口线程)，与您调用BeginXXX方法的线程不同。要了解更多细节，请查看Stephen Cleary的"There Is No Thread"。
管理员如何优先考虑哪些连接/阅读/写作必须先处理?
当没有IOCP线程可用来处理异步I/O操作的完成时，称为TheadPool饥饿。当所有池线程都在忙于执行某些代码(例如，处理接收到的套接字消息)，或者被阻塞调用(如WaitHandle.WaitOne())阻塞时，就会发生这种情况。在这种情况下，I/O完成例程排队到ThreadPool，以便在线程可用时以FIFO的方式执行。
您可以选择使用SetMinThreads/SetMaxThreads api来增加ThreadPool的大小，但这样做并不总是一个好主意。实际并发线程的数量无论如何都受到CPU/内核数量的限制，因此您宁愿尽快完成任何CPU限制的处理工作，并释放线程以返回池。