异步 IO

最新推荐文章于 2020-02-10 10:20:14 发布

原创最新推荐文章于 2020-02-10 10:20:14 发布 · 723 阅读

CC 4.0 BY-SA版权

异步 IO 节省了大量因为要同步一个流程，而使用 CPU 资源进行等待的时间。在这段时间内，我们可以做其它的事，然后再把当前线程挂起，或者直接挂起。注意，挂起线程后，线程是不占用 CPU 时间的。

异步 IO 必须结合事件通知或者回调才能完成。这在前一篇文章中已经说明了。上一篇文章还说了，基于回调的方法，回调函数实际上是由操作系统去执行的，所以它也有明显的缺点，即，如果回调函数过多，它必然会直接影响到系统性能。在这一点上，事件的通知方法要胜于回调。在等待的过程中，由于事件的阻塞，线程会被挂起，直到事件处于激发状态，则线程重新被调度。

有一篇文章讲的很好，来源：http://blog.youkuaiyun.com/fion45/article/details/12554339，现在复制到下边来，在关键的地方为了加强理解，我作了注解：

老陈有一个在外地工作的女儿，不能经常回来，老陈和她通过信件联系。他们的信会被邮递员投递到他们的信箱里。
　　这和Socket模型非常类似。下面我就以老陈接收信件为例讲解SocketI/O模型。
　　一：select模型
　　老陈非常想看到女儿的信。以至于他每隔10分钟就下楼检查信箱，看是否有女儿的信，在这种情况下，“下楼检查信箱”然后回到楼上耽误了老陈太多的时间，以至于老陈无法做其他工作。
　　select模型和老陈的这种情况非常相似：周而复始地去检查......如果有数据......接收/发送.......[注：这即是明显的同步模型]
　　使用线程来select应该是通用的做法：
procedure TListenThread.Execute;
var
　addr : TSockAddrIn;
　fd_read : TFDSet;
　timeout : TTimeVal;
　ASock,
　MainSock : TSocket;
　len, i : Integer;
begin
　MainSock := socket( AF_INET, SOCK_STREAM, IPPROTO_TCP );
　addr.sin_family := AF_INET;
　addr.sin_port := htons(5678);
　addr.sin_addr.S_addr := htonl(INADDR_ANY);
　bind( MainSock, @addr, sizeof(addr) );
　listen( MainSock, 5 );
　while (not Terminated) do
　begin
　　FD_ZERO( fd_read );
　　FD_SET( MainSock, fd_read );
　　timeout.tv_sec := 0;
　　timeout.tv_usec := 500;
　　if select( 0, @fd_read, nil, nil, @timeout ) > 0 then //至少有1个等待Accept的connection
　　begin
　　　if FD_ISSET( MainSock, fd_read ) then
　　　begin
　　　for i:=0 to fd_read.fd_count-1 do //注意，fd_count <= 64，也就是说select只能同时管理最多64个连接
　　　begin
　　　　len := sizeof(addr);
　　　　ASock := accept( MainSock, addr, len );
　　　　if ASock <> INVALID_SOCKET then
　　　　　....//为ASock创建一个新的线程，在新的线程中再不停地select
　　　　end;
　　　end; 　　
　　end;
　end; //while (not self.Terminated)
　shutdown( MainSock, SD_BOTH );
　closesocket( MainSock );
end;
　　二：WSAAsyncSelect模型
　　后来，老陈使用了微软公司的新式信箱。这种信箱非常先进，一旦信箱里有新的信件，盖茨就会给老陈打电话：喂，大爷，你有新的信件了！从此，老陈再也不必频繁上下楼检查信箱了，牙也不疼了，你瞅准了，蓝天......不是，微软......[这种方式是微软见长的，当操作系统接受网络中断后，它便投放一个窗口事件到对此网络事件感兴趣的应用程序的消息队列中，那个窗口事件是之前应用程序传递给内核的。由于每一个带有窗口的应用程序都有自己的消息队列，消息循环机制是遍历的驱动力，应用程序一定会得到这个消息（可能有延时），并且应用程序有能力将此事件投递给程序的某个具体窗口，于是，那个窗口的特定事件响应例程便会执行相应的处理代码

消息循环机制可能的代码如下：

MSG msg;

while(GetMessage(&msg, NULL, 0, 0))

{

TranslateMessage(&msg);

DispatchMessage(&msg);

}

每个程序的循环机制类似于此，当它得到了操作系统之前安放的消息时，便会调用 DispatchMessage ，DispatchMessage 函数将消息分发到消息的目标窗口，并且查找目标窗口过程函数，给窗口过程函数传递窗口句柄、消息、wParam、lParam等参数然后调用该函数。注意，调用回调函数的一定是我们的程序中消息泵所在的线程。可参见这篇文章：

《谁在调用那些回调函数》

这种模型的弱点在于，消息循环机制也是基于轮循的，而且，维持消息队列也是要耗费的，每一个网络事件会导致一个事件的产生，如果网络并发量很大，则消息循环机制可能来不及处理，因为它只能有一个窗口过程一个一个来处理，所以效率比较低。

]
　　微软提供的WSAAsyncSelect模型就是这个意思。
　　WSAAsyncSelect模型是Windows下最简单易用的一种Socket I/O模型。使用这种模型时，Windows会把网络事件以消息的形式通知应用程序。
　　首先定义一个消息标示常量：
const WM_SOCKET = WM_USER + 55;
　　再在主Form的private域添加一个处理此消息的函数声明：
private
procedure WMSocket(var Msg: TMessage); message WM_SOCKET;
　　然后就可以使用WSAAsyncSelect了：
var
　addr : TSockAddr;
　sock : TSocket;
　sock := socket( AF_INET, SOCK_STREAM, IPPROTO_TCP );
　addr.sin_family := AF_INET;
　addr.sin_port := htons(5678);
　addr.sin_addr.S_addr := htonl(INADDR_ANY);
　bind( m_sock, @addr, sizeof(SOCKADDR) );
　WSAAsyncSelect( m_sock, Handle, WM_SOCKET, FD_ACCEPT or FD_CLOSE );
　listen( m_sock, 5 );
　....
　　应用程序可以对收到WM_SOCKET消息进行分析，判断是哪一个socket产生了网络事件以及事件类型：
procedure TfmMain.WMSocket(var Msg: TMessage);
var
　sock : TSocket;
　addr : TSockAddrIn;
　addrlen : Integer;
　buf : Array [0..4095] of Char;
begin
　//Msg的WParam是产生了网络事件的socket句柄，LParam则包含了事件类型
　case WSAGetSelectEvent( Msg.LParam ) of
　FD_ACCEPT :
　　begin
　　　addrlen := sizeof(addr);
　　　sock := accept( Msg.WParam, addr, addrlen );
　　　if sock <> INVALID_SOCKET then
　　　　WSAAsyncSelect( sock, Handle, WM_SOCKET, FD_READ or FD_WRITE or FD_CLOSE );
　　end;
　　FD_CLOSE : closesocket( Msg.WParam );
　　FD_READ : recv( Msg.WParam, buf[0], 4096, 0 );
　　FD_WRITE : ;
　end;
end;
　　三：WSAEventSelect模型
　　后来，微软的信箱非常畅销，购买微软信箱的人以百万计数......以至于盖茨每天24小时给客户打电话，累得腰酸背痛，喝蚁力神都不好使。微软改进了他们的信箱：在客户的家中添加一个附加装置，这个装置会监视客户的信箱，每当新的信件来临，此装置会发出“新信件到达”声，提醒老陈去收信。盖茨终于可以睡觉了。

[每次有网络事件时，则会使事件处于触发状态，则等待这个事件的线程被重新调度，去处理那个网络事件]
　　同样要使用线程：
procedure TListenThread.Execute;
var
　hEvent : WSAEvent;
　ret : Integer;
　ne : TWSANetworkEvents;
　sock : TSocket;
　adr : TSockAddrIn;
　sMsg : String;
　Index,
　EventTotal : DWORD;
　EventArray : Array [0..WSA_MAXIMUM_WAIT_EVENTS-1] of WSAEVENT;
begin
　...socket...bind...
　hEvent := WSACreateEvent();
　WSAEventSelect( ListenSock, hEvent, FD_ACCEPT or FD_CLOSE );
　...listen...
　while ( not Terminated ) do
　begin
　　Index := WSAWaitForMultipleEvents( EventTotal, @EventArray[0], FALSE, WSA_INFINITE, FALSE );
　　FillChar( ne, sizeof(ne), 0 );
　　WSAEnumNetworkEvents( SockArray[Index-WSA_WAIT_EVENT_0], EventArray[Index-WSA_WAIT_EVENT_0], @ne );
　　if ( ne.lNetworkEvents and FD_ACCEPT ) > 0 then
　　begin
　　　if ne.iErrorCode[FD_ACCEPT_BIT] <> 0 then
　　　　continue;
　　　ret := sizeof(adr);
　　　sock := accept( SockArray[Index-WSA_WAIT_EVENT_0], adr, ret );
　　　if EventTotal > WSA_MAXIMUM_WAIT_EVENTS-1 then//这里WSA_MAXIMUM_WAIT_EVENTS同样是64
　　　begin
　　　　closesocket( sock );
　　　　continue;
　　　end;
　　　hEvent := WSACreateEvent();
　　　WSAEventSelect( sock, hEvent, FD_READ or FD_WRITE or FD_CLOSE );
　　　SockArray[EventTotal] := sock;
　　　EventArray[EventTotal] := hEvent;
　　　Inc( EventTotal );
　　end;
　　if ( ne.lNetworkEvents and FD_READ ) > 0 then
　　begin
　　　if ne.iErrorCode[FD_READ_BIT] <> 0 then
　　　　continue;
　　　　FillChar( RecvBuf[0], PACK_SIZE_RECEIVE, 0 );
　　　　ret := recv( SockArray[Index-WSA_WAIT_EVENT_0], RecvBuf[0], PACK_SIZE_RECEIVE, 0 );
　　　　......
　　　end;
　　end;
end;
　　

[剩下的模型都是操作系统帮我们接受了数据，完成之后再通知我们的！就好像我们没有访问 IO 一样，也就是说，我们感觉所有进程对 IO 的访问都是同时进行，同时完成的，这种技术叫“Overlapped I/O”，即重叠 I/O。后面几种模型的不同主要在于，IO 完成之后的通知方式，有的以回调函数通知（称为重叠 IO 完成例程，也称为可提醒 IO），有的通过触发一个事件内核对象通知，最后一种比较特殊，也是最高效的方法，称为 IOCP，IO 完成端口].

四：Overlapped I/O 事件通知模型
　　后来，微软通过调查发现，老陈不喜欢上下楼收发信件，因为上下楼其实很浪费时间。于是微软再次改进他们的信箱。新式的信箱采用了更为先进的技术，只要用户告诉微软自己的家在几楼几号，新式信箱会把信件直接传送到用户的家中，然后告诉用户，你的信件已经放到你的家中了！老陈很高兴，因为他不必再亲自收发信件了！

[这个模型很容易就能用于多个异步 IO 事件，原因在于，我们可以创造多个 Overlapped ，将每一个的成员：hEvent 置为不同的事件，那么，在 IO 完成后，自然就会触发相对应的事件，于是我们就可以得到通知！（可以使用 WaitForMultipleObjects 等待多个事件发生）]

　　Overlapped I/O 事件通知模型和WSAEventSelect模型在实现上非常相似，主要区别在“Overlapped”，Overlapped模型是让应用程序使用重叠数据结构(WSAOVERLAPPED)，一次投递一个或多个Winsock I/O请求。这些提交的请求完成后，应用程序会收到通知。什么意思呢？就是说，如果你想从socket上接收数据，只需要告诉系统，由系统为你接收数据，而你需要做的只是为系统提供一个缓冲区~~~~~
Listen线程和WSAEventSelect模型一模一样，Recv/Send线程则完全不同：
procedure TOverlapThread.Execute;
var
　dwTemp : DWORD;
　ret : Integer;
　Index : DWORD;
begin
　......
　while ( not Terminated ) do
　begin
　　Index := WSAWaitForMultipleEvents( FLinks.Count, @FLinks.Events[0], FALSE, RECV_TIME_OUT, FALSE );
　　Dec( Index, WSA_WAIT_EVENT_0 );
　　if Index > WSA_MAXIMUM_WAIT_EVENTS-1 then //超时或者其他错误
　　　continue;
　　WSAResetEvent( FLinks.Events[Index] );
　　WSAGetOverlappedResult( FLinks.Sockets[Index], FLinks.pOverlaps[Index], @dwTemp, FALSE,FLinks.pdwFlags[Index]^ );
　　if dwTemp = 0 then //连接已经关闭
　　begin
　　　......
　　　continue;
　　end else
　begin
　　fmMain.ListBox1.Items.Add( FLinks.pBufs[Index]^.buf );
　end;
　//初始化缓冲区
　FLinks.pdwFlags[Index]^ := 0;
　FillChar( FLinks.pOverlaps[Index]^, sizeof(WSAOVERLAPPED), 0 );
　FLinks.pOverlaps[Index]^.hEvent := FLinks.Events[Index];
　FillChar( FLinks.pBufs[Index]^.buf^, BUFFER_SIZE, 0 );
　//递一个接收数据请求
　WSARecv( FLinks.Sockets[Index], FLinks.pBufs[Index], 1, FLinks.pdwRecvd[Index]^, FLinks.pdwFlags[Index]^, FLinks.pOverlaps[Index], nil );
end;
end;

　　五：Overlapped I/O 完成例程模型
　　老陈接收到新的信件后，一般的程序是：打开信封----掏出信纸----阅读信件----回复信件......为了进一步减轻用户负担，微软又开发了一种新的技术：用户只要告诉微软对信件的操作步骤，微软信箱将按照这些步骤去处理信件，不再需要用户亲自拆信/阅读/回复了！老陈终于过上了小资生活！

[这种模型最初被微软吹捧为最有效的方式，它的设计思路是这样的：当系统创建一个线程的时候，会同时创建一个线程的异步过程调用（APC）队列。这个队列可以被线程和内核访问。当一个线程向操作系统/驱动提出一个 IO 请求，驱动即在线程的 APC 队列里面添加一项，它包括的内容为：overlapped 结构地址，完成函数地址。当 IO 完成后，且线程处于可提醒状态，系统检查 APC 队列，如果非空，则线程被调度，线程会接受驱动程序传递过来的IO错误码，已传输字节数，及 Overlapped 地址，以它们为参数去调用回调函数。处理完一个 IO 请求，则从 APC 中移除一个。当前线程循环处理，直到 APC 队列为空。前面说到，线程必须处于可提醒状态，系统才会中断线程的等待状态，使线程可调度，为了让一个线程处于可提醒状态，可以使用 SleepEx,WaitForSingleObjectEx,WaitForMultipleObjectEx 等 Ex 系列函数，将某些参数置为 TRUE。

回调函数用到的全局变量不需要同步，即使是多线程情况，记住：调用可提醒函数之一的线程与执行回调函数的线程是同一个线程。即，不会有多个线程来调用回调函数。

发出 IO 请求的线程必须同时对完成通知处理。如果一个线程发出多个请求，那么即使其他线程处于空闲状态，该线程也必须对每个请求完成通知做响应。这就没有负载均衡。

]

　　Overlapped I/O 完成例程要求用户提供一个回调函数，发生新的网络事件的时候系统将执行这个函数：
procedure WorkerRoutine( const dwError, cbTransferred : DWORD;
const
lpOverlapped : LPWSAOVERLAPPED; const dwFlags : DWORD ); stdcall;
　　然后告诉系统用WorkerRoutine函数处理接收到的数据：
WSARecv( m_socket, @FBuf, 1, dwTemp, dwFlag, @m_overlap, WorkerRoutine );
　　然后......没有什么然后了，系统什么都给你做了！微软真实体贴！
while ( not Terminated ) do//这就是一个Recv/Send线程要做的事情......什么都不用做啊！！！
begin
　if SleepEx( RECV_TIME_OUT, True ) = WAIT_IO_COMPLETION then //
　begin
　　;
　end else
　begin
　　continue;
　end;
end;
　　
六：IOCP模型
　　微软信箱似乎很完美，老陈也很满意。但是在一些大公司情况却完全不同！这些大公司有数以万计的信箱，每秒钟都有数以百计的信件需要处理，以至于微软信箱经常因超负荷运转而崩溃！需要重新启动！微软不得不使出杀手锏......
　　微软给每个大公司派了一名名叫“Completion Port”的超级机器人，让这个机器人去处理那些信件！
　　“Windows NT小组注意到这些应用程序的性能没有预料的那么高。特别的，处理很多同时的客户请求意味着很多线程并发地运行在系统中。因为所有这些线程都是可运行的 [没有被挂起和等待发生什么事]，Microsoft意识到NT内核花费了太多的时间来转换运行线程的上下文[Context]，线程就没有得到很多 CPU时间来做它们的工作。大家可能也都感觉到并行模型的瓶颈在于它为每一个客户请求都创建了一个新线程。创建线程比起创建进程开销要小，但也远不是没有开销的。我们不妨设想一下：如果事先开好N个线程，让它们在那hold[堵塞]，然后可以将所有用户的请求都投递到一个消息队列中去。然后那N个线程逐一从消息队列中去取出消息并加以处理。就可以避免针对每一个用户请求都开线程。不仅减少了线程的资源，也提高了线程的利用率。理论上很不错，你想我等泛泛之辈都能想出来的问题，Microsoft又怎会没有考虑到呢?”-----摘自nonocast的《理解I/O Completion Port》
　　[IO 完成端口结合了线程池与异步通知两个优点，可以在一个设备上，如 socket 创建一个完成端口，与设备关联，以后此设备上发生了事件，系统会通知到正在等待完成端口的所有线程（一般是一个线程池里面的所有线程都在调用 GetQueuedCompletionStatus 将自己挂起，等待被系统唤醒），然后有多个线程可能会被唤醒。]

先看一下IOCP模型的实现：
//创建一个完成端口
FCompletPort := CreateIoCompletionPort( INVALID_HANDLE_VALUE, 0,0,0 );
//接受远程连接，并把这个连接的socket句柄绑定到刚才创建的IOCP上
AConnect := accept( FListenSock, addr, len);
CreateIoCompletionPort( AConnect, FCompletPort, nil, 0 );
//创建CPU数*2 + 2个线程
for i:=1 to si.dwNumberOfProcessors*2+2 do
begin
　AThread := TRecvSendThread.Create( false );
　AThread.CompletPort := FCompletPort;//告诉这个线程，你要去这个IOCP去访问数据
end;
　　就这么简单，我们要做的就是建立一个IOCP，把远程连接的socket句柄绑定到刚才创建的IOCP上，最后创建n个线程，并告诉这n个线程到这个IOCP上去访问数据就可以了。
　　再看一下TRecvSendThread线程都干些什么：
procedure TRecvSendThread.Execute;
var
　......
begin
　while (not self.Terminated) do
　begin
　　//查询IOCP状态（数据读写操作是否完成）
　　GetQueuedCompletionStatus( CompletPort, BytesTransd, CompletKey, POVERLAPPED(pPerIoDat), TIME_OUT );
　　if BytesTransd <> 0 then
　　　....;//数据读写操作完成
　　
　　　//再投递一个读数据请求
　　　WSARecv( CompletKey, @(pPerIoDat^.BufData), 1, BytesRecv, Flags, @(pPerIoDat^.Overlap), nil );
　　end;
end;
　　
读写线程只是简单地检查IOCP是否完成了我们投递的读写操作，如果完成了则再投递一个新的读写请求。
　　应该注意到，我们创建的所有TRecvSendThread都在访问同一个IOCP（因为我们只创建了一个IOCP），并且我们没有使用临界区！难道不会产生冲突吗？不用考虑同步问题吗？
　　这正是IOCP的奥妙所在。IOCP不是一个普通的对象，不需要考虑线程安全问题。它会自动调配访问它的线程：如果某个socket上有一个线程A正在访问，那么线程B的访问请求会被分配到另外一个socket。这一切都是由系统自动调配的，我们无需过问。