激情综合中文娱乐网,国产精品制服诱惑,亚洲小视频在线

有关异步��d��、通信

chatler — Mon, 06 Sep 2010 09:33:00 GMT

��?/div>

一般来��_��单的异步�Q�Asynchronous�Q?调用是这样一�U�调用方式：发�v者请求一个异步调用，通知执行者，然后处理其他工作�Q�在某一个同步点�{�待执行者的完成�Q�执行者执行调用的实际操作�Q�完成后�?知发赯��。可以看出，在异步调用中有两�U�角�Ԍ��发�v者和执行者，它们都是能主动运行的对象�Q�我们称��Z��动对象，同时�q�有一个同步点�Q�主动对象在同步点协�?同步。在本文中，我们讨论主要是通用计算机、多�q�程多线�E�的分时操作�pȝ��上的异步调用。在操作�pȝ��的角度上来看�Q�主动对象包括了�q�程、线�E�和��g上的IC�{�，至于中断�Q�可以看作��L��在某个进�E�或者线�E�的上下文借用一下CPU。而同步操作可以通过操作�pȝ��得各�U�同步机�Ӟ��互斥锁，信号灯等�{�来完成�?/div>

我们可以先看看异步调用在Windows(本文中一般不加指出的话，都是�Ҏ��NT/2000)��d��文�g中的应用。Windows中的ReadFile和WriteFile都提供了异步的接口。以ReadFile��Z��Q?/div>

BOOL ReadFile(HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped);

如果最后一个参数lpOverlapped不�ؓNULL�Q��ƈ且文件以FILE_FLAG_OVERLAPPED 标志打开�Q�那么这个调用就是异步的�Q�ReadFile会立刻返回，如果操作没有立刻完成�Q�返回FALSE�q�且GetLastError()�q�回 ERROR_IO_PENDING�Q�，那么调用者可以在某个时刻通过WaitForSingleObject�{�函数来�{�待中的hEvent来等待操作完�?�Q�可能已�l�完成）�q�行同步�Q�当操作完成以后�Q�可以调用GetOverlappedResult者获得操作的�l�果�Q�比如是否成功，��d��了多��字节等�{�。这�?的发赯��就是应用程序，而执行者就是操作系�l�本�w�，至于执行者是怎么执行的，我们会在后面的篇�q�讨论。而两者的同步��是通过一个Windows Event来完成�?/div>

把这个异步调用的�q�程再抽象和扩展一些，我们可以把异步调用需要解决的问题归结��Z��个：一个是执行的动力，另一个是��d��对象的调度。简单来��_��前者是各个��d��对象�Q�线�E�、进�E�或者一些代码）是如何获得CPU�Q�后者是各个��d��对象如何协同工作�Q?保证操作的流�E�是协调正确的。一般来��_��q�程和线�E�都可以由操作系�l�直接调度而获得CPU�Q�而更�l�粒度的�Q�比如一些代码的调度�Q�往往��需要一个更复杂的模型（比如在操作系�l�内部的实现�Q�这时候线�E�的�_�度太粗了）。而主动对象的调度�Q�当参与者较��的时候，可以通过基本的同步机制来完成�Q�在更复杂的情况下，�?能通过一个schedule机制来做会更实际一些�?/div>

动力和调�?/div>

如前所�q�ͼ�异步调用主要需要解决两个问题：执行的动力和执行的调度。最普遍的情况就是，一个主导流�E�的调用者进�E�（�U�程�Q�，一个或多个工作者进�E�（�U�程�Q�，通过操作�pȝ��提供的同步机制来�?成异步调用。这个同步机制在扩展化的情�Ş下，是一个或多个栅栏Barrier�Q�对应于每个同步的执行点。所有需要在�q�个执行点同步的��d��对象会等待相应的 Barrier�Q�直到所有对象都完成。在一些简化的情�Ş�Q�比如说工作者�ƈ不关心调用者的同步�Q�那么这个Barrier可以��化成信号灯，在只有一个工作�?的情况下�Q�可以简化成一个Windows事�gEvent或者条件变�?Condition Variable�?/div>

现在来考虑复杂的情形。假设我们用一些线�E�来协作完成一��工作，各个�U�程的执行之间有先后��序上的限制�Q�而操作系�l�就是这��工作的调度者，负责在适当的时候调度适当的线�E�来获得CPU。显�Ӟ��q�发执行中的一个线�E�对于另外一个线�E�来��_��本质上就是异步的�Q�假如它们之间有调用关系�Q�那也就是一个异步调用。而操作系�l�可以通过�?本的同步机制使得合适的�U�程才被调度�Q�其他未完成的线�E�则处于�{�待状态。�D例说�Q�我们有4个线�E�A,B,C,D来完成一��工作，其中的顺序限制是 A>B;C>D�Q?#8220;>”表示左边的线�E�完成必��d��于右边的�U�程执行�Q��?#8220;;”表示两个�U�程可以同时�q�行。同时假设B的一个操作需要调�?C来完成，显而易见，�q�时候这个操作就是一个异步调用。我们可以在每个“>”的位�|�设定一个同步点�Q�然后通过一个信��L��来完成同步。线�E�B�Q�C�{�待 �W�一个信��L��Q�而D会等待第二个信号灯。这个例子的动力和调度都是通过操作�pȝ��的基本机�Ӟ��U�程调度和同步机�Ӟ��来完成�?/div>

把这个过�E�抽象一下，可以描述为：若干个主动对象（包括代码�Q�协调来完成一��工作，通过一个调度器来调度，实际上，�q�个调度器可能只是一些调度规则。显 �Ӟ��q�程或者线�E�只要被调度��p��获得CPU�Q�所以我们主要考虑代码�Q�比如一个函敎ͼ�怎么��h��能获得执行。用工作者线�E�来调用�q�个函数昄��是直观和通用的一个方案。事实上�Q�在用户�I�间(user space)或者用��h�?user mode)�Q�这个方法是很常用的。而在内核�?kernel mode)�Q�则可以通过中断来获得CPU�Q�这个通过注册IDT�?口和触发软中断就可以完成。硬件设备上的IC是另一个动力之源。而主动对象的调度�Q�最基本的也是前面说的各�U�同步机制。另一个常用的机制��是回调函数�Q�需要注意的是，回调函数一般会发生在跟调用者不一��L��上下文，比如说同一个进�E�的不同�U�程�Q�这个差别会带来一些限制。如果需要回调发生在调用者的�q�程�Q�线 �E�）上下文，则需要一些类似Unix下的signal或者Windows下的APC机制�Q�这一�Ҏ��们在后面会有所阐述。那么在回调函数里面一般作些什么事情呢�Q�最常用的，跟同步机制结合在一��P��当然��是释放一个互斥锁�Q�信��L��或者Windows Event�Q�Unix的条件变量）�{�等�Q�从而��得等待同步的其他对象可以得到调度而重新执行，实际上，也可以看作是通知调度器（操作�pȝ��Q�某些主动对�?�Q�等待同步的�Q�可以重新被调度了，从而调度器重新调度。但是对于另外一些调度器�Q�在�q�个�q�程中可能不需要同步对象的参与。在一些极端一些的例子里，调度�?至不要求严格有序的�?/div>

在实际应用中�Q�根据环境的限制�Q�异步调用的动力和调度的实现方式可以有很大差别。我们会在后面的例子里加以说明�?操作�pȝ��中的异步�Q�Windows的异步I/O�?/div>

Windows NT/2000是一个抢占式的分时操作系�l�。Windows的调度单位是�U�程�Q�它�?I/O架构是完全异步的�Q�也��是说同步的I/O实际上都��Z��异步I/O来完成。一个用��h��的�U�程��h��一个I/O的时候会��D��一个运行状态从user mode到kernel mode的�{变（操作�pȝ��把内核映��到每个�q�程�?G-4G的地址上，对于每个�q�程都是一��L��Q�。这个过�E�是通过中断调用内核输出的一些System Service来完成，比如说ReadFile实际上会执行NtReadFile�Q�ZwReadFile�Q�，需要注意的是，�q�行上下文仍然是当前�U�程�?NtReadFile的实现则��Z��Windows内核的异步I/O框架�Q�在I/O Manager的协助下完成。需要指出的是，I/O Manager只是��p��q�API构成的一个抽象概念，�q�没有一个真正的I/O Manager�U�程在运行�?/div>

Windows的I/O驱动�E�序是层�ơ堆�U�的。每个驱动程序会提供一致的接口以供初始化、清理和功能调用。驱动程序的调用��Z��I/O��h��包（I/O Request Packet, IRP�Q�，而不是像普通的函数调用那样使用栈来传递参数。操作系�l�和PnP��理器根据注册表�?适当的时机初始化和清理相应的驱动�E�序。在一般的功能调用的时候，IRP里面会指定功能调用号码以及相应的上下文或者参敎ͼ�I/O stack location�Q�。一个驱动程序可能调用别的驱动程序，�q�个�q�程可能是同步的�Q�线�E�上下文不改�?�Q�也可能是异步的。NtReadFile的实玎ͼ�大致是向最上层的驱动程序发��Z��个或多个IRP�Q�然后等待相应事件的完成�Q�同步的情况�Q�，或者直接返回（带Overlapped的情况）�Q�这些都在发赯��求的 �U�程执行�?/div>

当驱动程序处理IRP的时候，它可能立��d��成，也可能在中断里才能完成，比如��_��往��g讑֤�发出一个请求（通常可以是写 I/O port�Q�，当设备完成操作的时候会触发一个中断，然后在中断处理函数里得到操作�l�果。Windows有两�c�M��断，��g讑֤�的中断和软中断，分成若干个不同的优先�U�（IRQL�Q�。��Y中断主要有两�U�：DPC(Delayed Procedure Call)和APC(Asynchronous Procedure Call)�Q�都处于较低的优先��。驱动程序可以�ؓ��g中断注册ISR(Interrupt Service Routine)�Q�一般就是修改IDT某个条目的入口。同��P��操作�pȝ��也会为DPC和APC注册适当的中断处理例�E�（也是在IDT中）�?/div>

值得指出的是�Q�DPC是跟处理器相关的�Q�每个处理器会有一个DPC队列�Q�而APC是跟�U�程相关的，每个�U�程会有它的APC队列�Q�实际上包括一�?Kernel APC队列和User APC队列�Q�它们的调度�{�略有所区别�Q�，可以惌��Q�APC�q�不��严格意义上的中断，因�ؓ中断可能发生在�Q何一个线�E�的上下文中�Q�它被称��Z��断，主要是因�?IRQL的提升（从PASSIVE到APC�Q�，APC的调度一般在�U�程切换�{�等情�Ş下进行。当中断发生的时候，操作�pȝ��会调用中断处理例�E�，对于��g讑֤� 的ISR�Q�一般处理是兌��备中断，发出一个DPC��h��Q�然后返回。不在设备的中断处理中��用太多的CPU旉��Q�主要考虑是否则可能丢失别的中断。由于硬件设备中断的IRQL比DPC中断的高�Q�所以在ISR里面DPC会阻塞，直到ISR�q�回IRQL回到较低的水�q�I��才会触发DPC中断�Q�在 DPC中断里执行从��g讑֤��d��数据以及重新��h��、开中断�{�操作。ISR或者DPC可能在�Q何被中断的线�E�上下文�Q�arbitrary thread context�Q�执行，事实上线�E�的上下文是不可见的�Q�可以认为是�pȝ��借用一下时间片而已�?/div>

�ȝ��来说�Q�Windows的异步I/O�?构中�Q�主要有两种动力�Q�一是发赯��求的�U�程�Q�一部分内核代码会在�q�个�U�程上下文执行，二是ISR和DPC�Q�这部分内核代码会在中断里完成，可能使用��M��一个线�E�的上下文。而调度常见��用回调和事�g�Q�KEVENT�Q�，比如说在往下一层的驱动�E�序发出��h��的时候，可以指定一个完成例�E�Completion Routine�Q�当下层的驱动完成这个请求的时候会调用�q�个例程�Q�而往往在这个例�E�里�Q�就是简单的触发一下一个事件�?另外可以��Z��提一下Linux。Linux 2.6也有�c�M��的中断机�Ӟ��它有更多的��Y中断优先�U�，即不同优先��的softirq�Q�而类��g��DPC�Q�Linux也提供了专门的��Y中断�Q�对应DPC的就�?tasklet。Linux没有一个像windows�q�么一致的层次驱动�E�序架构�Q�所以它的异步I/O�E�微�_�糙一些，主要是通过以前的一些阻塞点�Q�现在直接返�?EIOCBRETRY�Q�而让调用者在合适的时机�l�箋重试。在�q�个�Ҏ��中，可以认�ؓ整个操作�׃��个函数完成，每次操作有进展时�Q�都把这个函��C��头执行一遍，当然已经完成的部分就不会再有实际的I/O。这��L��最大好处是原有的文件系�l�和驱动�E�序不用完全重写。而对于同步调用，只要��d��可以了�Q�这样对 �pȝ��的修改较��。这时候，要提供POSIX aio的语义，��可能需要提供一些用��L��E�来完成重试的过�E�了�Q�回想Windows可以通过中断和DPC完成的）。而对于Solaris�Q�也是类似的处理�Q�如果设备支持异步I/O�Q�那��通过中断可以完成�Q�否则就使用内部的LWP来模拟�?/div>

应用�E�序�Q�一个异步的HTTP服务器的设计

假设我们要设计一个HTTP服务器，它的设计目标包括�Q�高�q�发性、精�� Q�部分支持HTTP/1.1�Q�、支持plug-in�l�构。在不少场合可能都有�q�个需求。��M��上来��_��HTTP服务器可以类比成一个基于多�U�程的操作系 �l�：OS调度每个工作�U�程在适当的时候获得执行，而工作线�E�提供服务（也就是处理HTTP��h��Q�。在�q�个基础上，主要的考虑��是调度�_�度的大��，�_�度太大的时候�ƈ发性会降低�Q�而粒度太��又可能因�ؓ��d��切换�Q�考虑OS的Context Switching�Q�而导致效率降低，所以这又是一个折��L��l�果。类��g��Apache�Q�以及其他的HTTP服务器）�Q�我们可以把一个HTTP处理�q�程分�ؓ 若干个状态，��Z��q�些状态可以构造出一个HTTP处理的状态机。这�U�情况下�Q�我们就可以把每个状态的处理作�ؓ调度的粒度。一个调度过�E�就是：一个工作线�E?从全局的�Q务队列里取出一个HTTP_Context�l�构�Q�根据当前的状态完成相应处理；然后�Ҏ��状态机讄��下一个状态；再放回到全局的�Q务队列里。这�?子，若干个HTTP状态就可以通过�q�个调度�{�略构成一个完整HTTP处理�q�程。显而易见，一个状态对于下一个状态处理的调用都可以认为是异步的。一�?HTTP状态机的设计如下图所�C��?/div>

�?. HTTP状态机

工作�U�程的函数其实就是两个操作：从状态队列里取出一个HTTP_Context�Q�调用HTTP_Context的service()函数�Q�周而复此�?在这个架构上�Q�就很容易引入异步I/O和Plug-in的机制了。事实上我们也可以��用基于事�Ӟ��例如select/poll�Q�的I/O�{�略来模拟异步I /O�Q�实��C��使用一个用��L��E�就可以了�?/div>

对于异步I/O和Plug-in的调用，我们也是采用�c�M��于Linux 2.6里面aio的重试方案，而异步完成的时候采用回调函数。在某个状态上�Q�如果系�l�需要I/O操作�Q�recv或者send�Q�，则会��h��一个异步I /O�Q�操作系�l�提供的异步I/O或者由用户�U�程模拟的异步I/O�Q�，�q�时候相应的HTTP_Context不会重新回到状态队列里�Q�而在I/O完成的回�?函数里面才会重新攑֛�到状态队列，得到重新调度的机会。HTTP_Context得到重新调度的时候会��查I/O状态（�q�个可以通过一些标志位来完成）�Q?如果已经完成�Q�则处理然后讄��下一状态，重新调度�Q�否则可以重新请求一个新的I/O��h��。Plug-in也可以��用类似的�Ҏ��Q�比如说一个Plug-in 要跟外部的一个服务器通信�Q�这时候就可以在通信完成的时候才把HTTP_Context重新攑֛�到状态队列。显�Ӟ��Plug-in跟HTTP状态是多对�?的关�p�，一个Plug-in可以在若�q�个兛_��的状态注册自�w�，同时�q�可以设�|�一些short-path来提高处理的效率�?/div>

�l�论

�ȝ��来说�Q�异步调用的设计和应用归根结底就是对多个��d��对象的管理问题：如何提供执行的动力以及如何保证执行的��序逻辑。主要考虑的问题是��d��对象的粒度以及执行方式，同步或者回调来完成��序的调度，或者��用近似的调度而加一些鲁��的错误处理机制来保证语义的正确。后者可以考虑在��用基于事件的 socket的时候，readable事�g的通知可以是冗余的�Q�或者说可以比实际中发生的readable事�g更多�Q�这个时候��用非��d��的socket, 有些read()�Q�或者recv()�Q�会直接�q�回EWOULDBLOCK�Q�系�l�只要考虑处理�q�种情况�Q��用non blocking socket而不是blocking socket�Q�，当例外的情况不多的时候是可以接受的。这时候可以说事�g的报告就只是�q�似的�?/div>

from:

http://hi.baidu.com/hytjfxk/blog/item/d9262cdfcb298c14632798b3.html

chatler 2010-09-06 17:33 发表评论

一个基于完成端口的TCP Server Framework,��析IOCP

chatler — Wed, 25 Aug 2010 12:42:00 GMT

如果你不投递（POST�Q�Overlapped I/O�Q�那么I/O Completion Ports 只能��Z��提供一个Queue.
    CreateIoCompletionPort的NumberOfConcurrentThreads�Q?/span>
1.只有当第二个参数ExistingCompletionPort为NULL时它才有效，它是个max threads limits.
2.大家有谁把它讄��出cpu个数的��|��当然不只是cpu个数�?倍，而是下面的MAX_THREADS 100甚至更大�?/span>
对于�q�个值的讑֮��Q�msdn�q�没有说非得设成cpu个数�?倍，而且也没有把减少�U�程之间上下文交换这些媄响扯到这里来。I/O Completion Ports MSDN:"If your transaction required a lengthy computation, a larger concurrency value will allow more threads to run. Each completion packet may take longer to finish, but more completion packets will be processed at the same time. "�?/span>
    对于struct OVERLAPPED�Q�我们常会如下扩展，
typedef struct {
WSAOVERLAPPED overlapped; //must be first member?   是的�Q�必��L��W�一个。如果你不肯定，你可以试试�?/span>
SOCKET client_s;
SOCKADDR_IN client_addr;
WORD optCode;//1--read,2--send. 有�h�怼�定义�q�个数据成员�Q�但也有��Z��用，争议在send/WSASend,此时的同步和异步是否有必要？臛_��我下面的server更本��没用它�?/span>
char buf[MAX_BUF_SIZE];
WSABUF wsaBuf;//inited ? �q�个不要忘了�Q?/span>
DWORD numberOfBytesTransferred;
DWORD flags;

}QSSOverlapped;//for per connection
我下面的server框架的基本思想�?
One connection VS one thread in worker thread pool ,worker thread performs completionWorkerRoutine.
A Acceptor thread 专门用来accept socket,兌��至IOCP,�q�WSARecv:post Recv Completion Packet to IOCP.
在completionWorkerRoutine中有以下的职�?
1.handle request,当忙时增加completionWorkerThread数量但不��过maxThreads,post Recv Completion Packet to IOCP.
2.timeout时检查是否空闲和当前completionWorkerThread数量,当空闲时保持或减��至minThreads数量.
3.�Ҏ��有Accepted-socket��理生命周期,�q�里利用�pȝ��的keepalive probes,若想实现业务�?心蟩探测"只需��QSS_SIO_KEEPALIVE_VALS_TIMEOUT 改回�pȝ��默认�?��时.
下面�l�合源代�?��析一下IOCP:
socketserver.h
#ifndef __Q_SOCKET_SERVER__
#define __Q_SOCKET_SERVER__
#include
#include
#define QSS_SIO_KEEPALIVE_VALS_TIMEOUT 30*60*1000
#define QSS_SIO_KEEPALIVE_VALS_INTERVAL 5*1000

#define MAX_THREADS 100
#define MAX_THREADS_MIN 10
#define MIN_WORKER_WAIT_TIMEOUT 20*1000
#define MAX_WORKER_WAIT_TIMEOUT 60*MIN_WORKER_WAIT_TIMEOUT

#define MAX_BUF_SIZE 1024

/*当Accepted socket和socket关闭或发生异常时回调CSocketLifecycleCallback*/
typedef void (*CSocketLifecycleCallback)(SOCKET cs,int lifecycle);//lifecycle:0:OnAccepted,-1:OnClose//注意OnClose此时的socket未必可用,可能已经被非正常关闭或其他异�?

/*协议处理回调*/
typedef int (*InternalProtocolHandler)(LPWSAOVERLAPPED overlapped);//return -1:SOCKET_ERROR

typedef struct Q_SOCKET_SERVER SocketServer;
DWORD initializeSocketServer(SocketServer ** ssp,WORD passive,WORD port,CSocketLifecycleCallback cslifecb,InternalProtocolHandler protoHandler,WORD minThreads,WORD maxThreads,long workerWaitTimeout);
DWORD startSocketServer(SocketServer *ss);
DWORD shutdownSocketServer(SocketServer *ss);

#endif
qsocketserver.c      ��U?qss,相应的OVERLAPPED��U�qssOl.
#include "socketserver.h"
#include "stdio.h"
typedef struct {
WORD passive;//daemon
WORD port;
WORD minThreads;
WORD maxThreads;
volatile long lifecycleStatus;//0-created,1-starting, 2-running,3-stopping,4-exitKeyPosted,5-stopped
long workerWaitTimeout;//wait timeout
CRITICAL_SECTION QSS_LOCK;
volatile long workerCounter;
volatile long currentBusyWorkers;
volatile long CSocketsCounter;//Accepted-socket引用计数
CSocketLifecycleCallback cslifecb;
InternalProtocolHandler protoHandler;
WORD wsaVersion;//=MAKEWORD(2,0);
WSADATA wsData;
SOCKET server_s;
SOCKADDR_IN serv_addr;
HANDLE iocpHandle;
}QSocketServer;

typedef struct {
WSAOVERLAPPED overlapped;
SOCKET client_s;
SOCKADDR_IN client_addr;
WORD optCode;
char buf[MAX_BUF_SIZE];
WSABUF wsaBuf;
DWORD numberOfBytesTransferred;
DWORD flags;
}QSSOverlapped;

DWORD acceptorRoutine(LPVOID);
DWORD completionWorkerRoutine(LPVOID);

static void adjustQSSWorkerLimits(QSocketServer *qss){
  /*adjust size and timeout.*/
  /*if(qss->maxThreads <= 0) {
   qss->maxThreads = MAX_THREADS;
        } else if (qss->maxThreads < MAX_THREADS_MIN) {
        qss->maxThreads = MAX_THREADS_MIN;
        }
        if(qss->minThreads > qss->maxThreads) {
        qss->minThreads = qss->maxThreads;
        }
        if(qss->minThreads <= 0) {
            if(1 == qss->maxThreads) {
            qss->minThreads = 1;
            } else {
            qss->minThreads = qss->maxThreads/2;
            }
        }

        if(qss->workerWaitTimeout        qss->workerWaitTimeout=MIN_WORKER_WAIT_TIMEOUT;
        if(qss->workerWaitTimeout>MAX_WORKER_WAIT_TIMEOUT)
        qss->workerWaitTimeout=MAX_WORKER_WAIT_TIMEOUT;        */
}

typedef struct{
QSocketServer * qss;
HANDLE th;
}QSSWORKER_PARAM;

static WORD addQSSWorker(QSocketServer *qss,WORD addCounter){
WORD res=0;
if(qss->workerCounterminThreads||(qss->currentBusyWorkers==qss->workerCounter&&qss->workerCountermaxThreads)){
  DWORD threadId;
  QSSWORKER_PARAM * pParam=NULL;
  int i=0;
  EnterCriticalSection(&qss->QSS_LOCK);
  if(qss->workerCounter+addCounter<=qss->maxThreads)
   for(;i   {
    pParam=malloc(sizeof(QSSWORKER_PARAM));
    if(pParam){
     pParam->th=CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)completionWorkerRoutine,pParam,CREATE_SUSPENDED,&threadId);
     pParam->qss=qss;
     ResumeThread(pParam->th);
     qss->workerCounter++,res++;
    }
   }
  LeaveCriticalSection(&qss->QSS_LOCK);
}
return res;
}

static void SOlogger(const char * msg,SOCKET s,int clearup){
perror(msg);
if(s>0)
closesocket(s);
if(clearup)
WSACleanup();
}

static int _InternalEchoProtocolHandler(LPWSAOVERLAPPED overlapped){
QSSOverlapped *qssOl=(QSSOverlapped *)overlapped;

printf("numOfT:%d,WSARecvd:%s,\n",qssOl->numberOfBytesTransferred,qssOl->buf);
//Sleep(500);
return send(qssOl->client_s,qssOl->buf,qssOl->numberOfBytesTransferred,0);
}

DWORD initializeSocketServer(SocketServer ** ssp,WORD passive,WORD port,CSocketLifecycleCallback cslifecb,InternalProtocolHandler protoHandler,WORD minThreads,WORD maxThreads,long workerWaitTimeout){
QSocketServer * qss=malloc(sizeof(QSocketServer));
qss->passive=passive>0?1:0;
qss->port=port;
qss->minThreads=minThreads;
qss->maxThreads=maxThreads;
qss->workerWaitTimeout=workerWaitTimeout;
qss->wsaVersion=MAKEWORD(2,0);
qss->lifecycleStatus=0;
InitializeCriticalSection(&qss->QSS_LOCK);
qss->workerCounter=0;
qss->currentBusyWorkers=0;
qss->CSocketsCounter=0;
qss->cslifecb=cslifecb,qss->protoHandler=protoHandler;
if(!qss->protoHandler)
qss->protoHandler=_InternalEchoProtocolHandler;
adjustQSSWorkerLimits(qss);
*ssp=(SocketServer *)qss;
return 1;
}

DWORD startSocketServer(SocketServer *ss){
QSocketServer * qss=(QSocketServer *)ss;
if(qss==NULL||InterlockedCompareExchange(&qss->lifecycleStatus,1,0))
return 0;
qss->serv_addr.sin_family=AF_INET;
qss->serv_addr.sin_port=htons(qss->port);
qss->serv_addr.sin_addr.s_addr=INADDR_ANY;//inet_addr("127.0.0.1");
if(WSAStartup(qss->wsaVersion,&qss->wsData)){
/*�q�里�q�有个插曲就是这个WSAStartup被调用的时�?它居然会启动一条额外的�U�程,当然�E�后�q�条�U�程会自动退出的.不知WSAClearup又会如何?......*/

  SOlogger("WSAStartup failed.\n",0,0);
  return 0;
}
qss->server_s=socket(AF_INET,SOCK_STREAM,IPPROTO_IP);
if(qss->server_s==INVALID_SOCKET){
  SOlogger("socket failed.\n",0,1);
  return 0;
}
if(bind(qss->server_s,(LPSOCKADDR)&qss->serv_addr,sizeof(SOCKADDR_IN))==SOCKET_ERROR){
  SOlogger("bind failed.\n",qss->server_s,1);
  return 0;
}
if(listen(qss->server_s,SOMAXCONN)==SOCKET_ERROR)/*�q�里来谈�?strong>backlog,很多��Z��知道设成何�?我见到过1,5,50,100�?有�h说设定的��大��耗资�?的确,�q�里设成SOMAXCONN不代表windows会真的��用SOMAXCONN,而是" If set to SOMAXCONN, the underlying service provider responsible for socket s will set the backlog to a maximum reasonable value. "�Q�同时在现实环境中，不同操作�pȝ��支持TCP�~�冲队列有所不同�Q�所以还不如让操作系�l�来军_��它的倹{��像Apache�q�种服务器：
#ifndef DEFAULT_LISTENBACKLOG
#define DEFAULT_LISTENBACKLOG 511
#endif
*/
    {
  SOlogger("listen failed.\n",qss->server_s,1);
        return 0;
    }
qss->iocpHandle=CreateIoCompletionPort(INVALID_HANDLE_VALUE,NULL,0,/*NumberOfConcurrentThreads-->*/qss->maxThreads);
//initialize worker for completion routine.
addQSSWorker(qss,qss->minThreads);
qss->lifecycleStatus=2;
{
  QSSWORKER_PARAM * pParam=malloc(sizeof(QSSWORKER_PARAM));
  pParam->qss=qss;
  pParam->th=NULL;
  if(qss->passive){
   DWORD threadId;
   pParam->th=CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)acceptorRoutine,pParam,0,&threadId);
  }else
   return acceptorRoutine(pParam);
}
return 1;
}

DWORD shutdownSocketServer(SocketServer *ss){
QSocketServer * qss=(QSocketServer *)ss;
if(qss==NULL||InterlockedCompareExchange(&qss->lifecycleStatus,3,2)!=2)
  return 0;
closesocket(qss->server_s/*listen-socket*/);//..other accepted-sockets associated with the listen-socket will not be closed,except WSACleanup is called..
if(qss->CSocketsCounter==0)
  qss->lifecycleStatus=4,PostQueuedCompletionStatus(qss->iocpHandle,0,-1,NULL);
WSACleanup();
return 1;
}

DWORD  acceptorRoutine(LPVOID ss){
QSSWORKER_PARAM * pParam=(QSSWORKER_PARAM *)ss;
QSocketServer * qss=pParam->qss;
HANDLE curThread=pParam->th;
QSSOverlapped *qssOl=NULL;
SOCKADDR_IN client_addr;
int client_addr_leng=sizeof(SOCKADDR_IN);
SOCKET cs;
free(pParam);
while(1){
  printf("accept starting.....\n");
  cs/*Accepted-socket*/=accept(qss->server_s,(LPSOCKADDR)&client_addr,&client_addr_leng);
  if(cs==INVALID_SOCKET)
        {
   printf("accept failed:%d\n",GetLastError());
            break;
        }else{//SO_KEEPALIVE,SIO_KEEPALIVE_VALS �q�里是利用系�l�的"心蟩探测",keepalive probes.linux:setsockopt,SOL_TCP:TCP_KEEPIDLE,TCP_KEEPINTVL,TCP_KEEPCNT
            struct tcp_keepalive alive,aliveOut;
            int so_keepalive_opt=1;
            DWORD outDW;
            if(!setsockopt(cs,SOL_SOCKET,SO_KEEPALIVE,(char *)&so_keepalive_opt,sizeof(so_keepalive_opt))){
               alive.onoff=TRUE;
               alive.keepalivetime=QSS_SIO_KEEPALIVE_VALS_TIMEOUT;
               alive.keepaliveinterval=QSS_SIO_KEEPALIVE_VALS_INTERVAL;
               if(WSAIoctl(cs,SIO_KEEPALIVE_VALS,&alive,sizeof(alive),&aliveOut,sizeof(aliveOut),&outDW,NULL,NULL)==SOCKET_ERROR){
                    printf("WSAIoctl SIO_KEEPALIVE_VALS failed:%d\n",GetLastError());
                    break;
                }

            }else{
                     printf("setsockopt SO_KEEPALIVE failed:%d\n",GetLastError());
                     break;
            }
  }

  CreateIoCompletionPort((HANDLE)cs,qss->iocpHandle,cs,0);
  if(qssOl==NULL){
   qssOl=malloc(sizeof(QSSOverlapped));
  }
  qssOl->client_s=cs;
  qssOl->wsaBuf.len=MAX_BUF_SIZE,qssOl->wsaBuf.buf=qssOl->buf,qssOl->numberOfBytesTransferred=0,qssOl->flags=0;//initialize WSABuf.
  memset(&qssOl->overlapped,0,sizeof(WSAOVERLAPPED));
  {
   DWORD lastErr=GetLastError();
   int ret=0;
   SetLastError(0);
   ret=WSARecv(cs,&qssOl->wsaBuf,1,&qssOl->numberOfBytesTransferred,&qssOl->flags,&qssOl->overlapped,NULL);
   if(ret==0||(ret==SOCKET_ERROR&&GetLastError()==WSA_IO_PENDING)){
    InterlockedIncrement(&qss->CSocketsCounter);//Accepted-socket计数递增.
    if(qss->cslifecb)
     qss->cslifecb(cs,0);
    qssOl=NULL;
   }

   if(!GetLastError())
    SetLastError(lastErr);
  }

  printf("accept flags:%d ,cs:%d.\n",GetLastError(),cs);
}//end while.

if(qssOl)
  free(qssOl);
if(qss)
  shutdownSocketServer((SocketServer *)qss);
if(curThread)
  CloseHandle(curThread);

return 1;
}

static int postRecvCompletionPacket(QSSOverlapped * qssOl,int SOErrOccurredCode){
int SOErrOccurred=0;
DWORD lastErr=GetLastError();
SetLastError(0);
//SOCKET_ERROR:-1,WSA_IO_PENDING:997
if(WSARecv(qssOl->client_s,&qssOl->wsaBuf,1,&qssOl->numberOfBytesTransferred,&qssOl->flags,&qssOl->overlapped,NULL)==SOCKET_ERROR
  &&GetLastError()!=WSA_IO_PENDING)//this case lastError maybe 64, 10054
{
  SOErrOccurred=SOErrOccurredCode;
}
if(!GetLastError())
  SetLastError(lastErr);
if(SOErrOccurred)
  printf("worker[%d] postRecvCompletionPacket SOErrOccurred=%d,preErr:%d,postedErr:%d\n",GetCurrentThreadId(),SOErrOccurred,lastErr,GetLastError());
return SOErrOccurred;
}

DWORD  completionWorkerRoutine(LPVOID ss){
QSSWORKER_PARAM * pParam=(QSSWORKER_PARAM *)ss;
QSocketServer * qss=pParam->qss;
HANDLE curThread=pParam->th;
QSSOverlapped * qssOl=NULL;
DWORD numberOfBytesTransferred=0;
ULONG_PTR completionKey=0;
int postRes=0,handleCode=0,exitCode=0,SOErrOccurred=0;
free(pParam);
while(!exitCode){
  SetLastError(0);
  if(GetQueuedCompletionStatus(qss->iocpHandle,&numberOfBytesTransferred,&completionKey,(LPOVERLAPPED *)&qssOl,qss->workerWaitTimeout)){
   if(completionKey==-1&&qss->lifecycleStatus>=4)
   {
    printf("worker[%d] completionKey -1:%d \n",GetCurrentThreadId(),GetLastError());
    if(qss->workerCounter>1)
     PostQueuedCompletionStatus(qss->iocpHandle,0,-1,NULL);
    exitCode=1;
    break;
   }
   if(numberOfBytesTransferred>0){

    InterlockedIncrement(&qss->currentBusyWorkers);
    addQSSWorker(qss,1);
    handleCode=qss->protoHandler((LPWSAOVERLAPPED)qssOl);
    InterlockedDecrement(&qss->currentBusyWorkers);

    if(handleCode>=0){
     SOErrOccurred=postRecvCompletionPacket(qssOl,1);
    }else
     SOErrOccurred=2;
   }else{
    printf("worker[%d] numberOfBytesTransferred==0 ***** closesocket servS or cs *****,%d,%d ,ol is:%d\n",GetCurrentThreadId(),GetLastError(),completionKey,qssOl==NULL?0:1);
    SOErrOccurred=3;
   }
  }else{ //GetQueuedCompletionStatus rtn FALSE, lastError 64 ,995[timeout worker thread exit.] ,WAIT_TIMEOUT:258
   if(qssOl){
    SOErrOccurred=postRecvCompletionPacket(qssOl,4);
   }else {

    printf("worker[%d] GetQueuedCompletionStatus F:%d \n",GetCurrentThreadId(),GetLastError());
    if(GetLastError()!=WAIT_TIMEOUT){
     exitCode=2;
    }else{//wait timeout
     if(qss->lifecycleStatus!=4&&qss->currentBusyWorkers==0&&qss->workerCounter>qss->minThreads){
      EnterCriticalSection(&qss->QSS_LOCK);
      if(qss->lifecycleStatus!=4&&qss->currentBusyWorkers==0&&qss->workerCounter>qss->minThreads){
       qss->workerCounter--;//until qss->workerCounter decrease to qss->minThreads
       exitCode=3;
      }
      LeaveCriticalSection(&qss->QSS_LOCK);
     }
    }
   }
  }//end GetQueuedCompletionStatus.

  if(SOErrOccurred){
   if(qss->cslifecb)
    qss->cslifecb(qssOl->client_s,-1);
   /*if(qssOl)*/{
    closesocket(qssOl->client_s);
    free(qssOl);
   }
   if(InterlockedDecrement(&qss->CSocketsCounter)==0&&qss->lifecycleStatus>=3){
    //for qss workerSize,PostQueuedCompletionStatus -1
    qss->lifecycleStatus=4,PostQueuedCompletionStatus(qss->iocpHandle,0,-1,NULL);
    exitCode=4;
   }
  }
  qssOl=NULL,numberOfBytesTransferred=0,completionKey=0,SOErrOccurred=0;//for net while.
}//end while.

//last to do
if(exitCode!=3){
  int clearup=0;
  EnterCriticalSection(&qss->QSS_LOCK);
  if(!--qss->workerCounter&&qss->lifecycleStatus>=4){//clearup QSS
    clearup=1;
  }
  LeaveCriticalSection(&qss->QSS_LOCK);
  if(clearup){
   DeleteCriticalSection(&qss->QSS_LOCK);
   CloseHandle(qss->iocpHandle);
   free(qss);
  }
}
CloseHandle(curThread);
return 1;
}
------------------------------------------------------------------------------------------------------------------------
对于IOCP的LastError的��L别和处理是个隄��,所以请注意我的completionWorkerRoutine的while�l�构,
�l�构如下:
while(!exitCode){
    if(completionKey==-1){...break;}
    if(GetQueuedCompletionStatus){/*在这个if体中只要你投递的OVERLAPPED is not NULL,那么�q�里你得到的��是�?/strong>.*/
        if(numberOfBytesTransferred>0){
               /*在这里handle request,记得要��l�投递你的OVERLAPPED�? */
        }else{
              /*�q�里可能客户端或服务端closesocket(the socket),但是OVERLAPPED is not NULL,只要你投递的不�ؓNULL!*/
        }
    }else{/*在这里的if体中,虽然GetQueuedCompletionStatus return FALSE,但是不代表OVERLAPPED一定�ؓNULL.特别是OVERLAPPED is not NULL的情况下,不要以�ؓLastError发生�?��׃��表当前的socket无用或发生致命的异常,比如发生lastError:995�q�种情况下此时的socket有可能是一切正常的可用�?你不应该关闭�?/strong>.*/
        if(OVERLAPPED is not NULL){
             /*�q�种情况�?请不��?7,21�l�箋投递吧!在投递后再检��错�?/strong>.*/
        }else{

        }
    }
if(socket error occured){

}
prepare for next while.
}

行文仓促,隑օ�有错误或不��之处,希望大家�t�跃指正评论,谢谢!

�q�个模型在性能上还是有改进的空间哦�Q?/strong>

from:
http://www.shnenglu.com/adapterofcoms/archive/2010/06/26/118781.aspx

chatler 2010-08-25 20:42 发表评论

IOCP

chatler — Wed, 05 May 2010 07:51:00 GMT
关于IOCP�Q�先看微软的MSDN上讲的这一�D�：
http://msdn.microsoft.com/en-us/library/aa365198%28v=VS.85%29.aspx

另外�Q�下面这个讲的也�q�是不错的�?br>http://www.shnenglu.com/kevinlynx/archive/2008/06/23/54390.html

IOCP 与线�E?/a>

author : Kevin Lynx

什么是完成包？

完成包，即IO Completion Packet�Q�是指异步IO操作完毕后OS提交�l�应用层的通知包。IOCP�l�护了一个IO操作�l�果队列�Q�里�?br>保存着各种完成包。应用层调用 GQCS(也就是GetQueueCompletionStatus)函数获取�q�些完成包�?

最大�ƈ发线�E�数

在一个典型的 IOCP�E�序里，会有一些线�E�调用GQCS去获取IO操作�l�果。最大�ƈ发线�E�数指定在同一时刻处理完成包的�U�程数目�?br>该参数在调用 CreateIoCompletionPort时由NumberOfConcurrentThreads指定�?

工作者线�E?/strong>

工作者线�E�一般指�? ��是调用GQCS函数的线�E�。要注意的是�Q�工作者线�E�数和最大�ƈ发线�E�数�q�不是同一回事(见下�?。工作�?br>�U�程由应用层昄��创徏 (_beginthreadex 之类)。工作者线�E�通常是一个��@环，会不断地GQCS到完成包�Q�然后处理完成包�?

调度�q�程

工作者线�E�以是否��d�� 分�ؓ两种状态：�q�行状态和�{�待状态。当�U�程做一些阻塞操作时(�U�程同步�Q�甚至GQCS�I�的完成队列)�Q�线�E?br>处于�{�待状态；否则�Q�线�E�处于运行状态�?

另一斚w��Q�OS会始�l�保持某一时刻处于�q�行状态的�U�程数小于最大�ƈ发线�E�数。每一�? 调用GQCS函数的线�E�OS实际上都会进行记录，
当完成队列里有完成包�Ӟ��OS会首先检查当前处于运行状态的工作�U�程数是否小于最大�ƈ发线�E�数�Q? 如果��于�Q�OS会按照LIFO的顺
序让某个工作者线�E�从GQCS�q�回(此工作者线�E��{换�ؓ�q�行状�?。如何决定这个LIFO�Q�这是简单地通过调用 GQCS函数的顺序决定的�?

从这里可以看出，�q�里涉及到线�E�唤醒和睡眠的操作。如果两�? �U�程被放�|�于同一个CPU上，��׃��有线�E�切换的开销。因此，��Z��?br>除这个开销�Q�最大�ƈ发线�E�数被徏议�ؓ讄��成CPU数量�?

从以上调度过�E�还可以看出�Q�如果某个处于运行状态的工作者线�E�在处理完成包时��d��?例如�U�程同步、其他IO操作)�Q�那么就�?br>CPU 资源处于�I�闲状态。因此，我们也看到很多文档里��Q�工作者线�E�数�?CPU�?2+2)�?

在一个等待线�E��{换到�q�行状态时�Q�有可能会出现短暂的旉��q�行�U�程数超�q�最大�ƈ发线�E�数�Q�这个时候OS会迅速地让这个新转换
�? �U�程��d��Q�从而减��这个数量�?关于�q�个观点�Q�MSDN上只��_��by not allowing any new active threads�Q�却没说明not allowing
what)

�? 度原�?/strong>

�q�个知道了其实没什么意义，都是内核做的事，大致上都是操作线 �E�control block�Q�直接摘�?lt;Inside IO Completion Ports>:

The list of threads hangs off the queue object. A thread's control block data structure has a pointer in it that
references the queue object of a queue that it is associated with; if the pointer is NULL then the thread is not
associated with a queue.

So how does NT keep track of threads that become inactive because they block on something other than the completion
port" The answer lies in the queue pointer in a thread's control block. The scheduler routines that are executed
in response to a thread blocking (KeWaitForSingleObject, KeDelayExecutionThread, etc.) check the thread's queue
pointer and if its not NULL they will call KiActivateWaiterQueue, a queue-related function. KiActivateWaiterQueue
decrements the count of active threads associated with the queue, and if the result is less than the maximum and
there is at least one completion packet in the queue then the thread at the front of the queue's thread list is
woken and given the oldest packet. Conversely, whenever a thread that is associated with a queue wakes up after
blocking the scheduler executes the function KiUnwaitThread, which increments the queue's active count.

�? 考资�?/strong>
:
http://technet.microsoft.com/en-us/sysinternals/bb963891.aspx
:
http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx
:
http://support.microsoft.com/kb/192800/en-us/

chatler 2010-05-05 15:51 发表评论

chatler — Tue, 27 Apr 2010 16:10:00 GMT

(VC�~�译器下)

1. CALLBACK�Q?/strong>WINAPI�?/strong>AFXAPI到底是什么？它们分别在什么地�? 被定义的�Q?/strong>

在头文�gwindef.h中，CALLBACK, WINAPI, APIENTRY

……

#define CALLBACK __stdcall

#define WINAPI         __stdcall

#define WINAPIV       __cdecl

#define APIENTRY    WINAPI

……

在头文�gAFXVER_.H中，AFXAPI的定义如下：

    ……

   // AFXAPI is used on global public functions

#ifndef AFXAPI

        #define AFXAPI __stdcall

#endif

    ……

2. __stdcall�?/strong>__cdecl有什么作用？他们的区别是什么？

a. __stdcall是新标准C/C++函数的调用方法。从底层上说�Q��用这�U�调用方法参数的�q�栈��序�? 标准C调用(__cdecl�Ҏ��)是一��L��,�?/p>
  是从叛_��?但是__stdcall采用自动清栈的方式，而__cdecl是手工清栈�?/p>

b. windows规定,凡事由它来负责调用的函数必须定义为_stdcall�c�d��Q�比如回调函数、WinMain函数�{��?/p>

c. 如果没有显试声明的话�Q�函数的调用�Ҏ��默认是__cdecl�?/p>

3. 调用�U�定�U�类

   一共有5中函数调用约�?calling convention)�Q�它军_��一下内容：

   1) 函数参数的压栈顺�?/p>
   2) ��p��用者还是被调用者把参数弹出�?/p>
   3) 产生函数修饰名的�Ҏ��

__stdcall调用�U�定�Q?/p>
函数的参数自叛_��左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，

__cdecl调用�U�定�Q?/p>
是C和C++�E�序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码，所以��生的可执行文件大��会比调用__stdcall函数的大。函数采用从叛_��左的压栈方式。注意：对于可变参数的成员函敎ͼ�始终使用__cdecl的�{换方式�?/p>

__fastcall调用�U�定�Q?/p>
它是通过寄存器来传送参数的(实际上，它用ECX和EDX传送前两个双字(DWORD)或更��的参数�Q�剩下的参数仍旧自右向左压栈传送，被调用的函数�? �q�回前清理传送参数的内存�?�?/p>

thiscall调用�U�定�Q?/p>
仅仅应用�?C++"�? 员函数。this�? 针存放于CX寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定�?/p>

naked call调用�U�定�Q?/p>
采用上述4�U�调用约定时�Q�如果必要的话，�q�入函数时编译器会��生代码来保存ESI�Q�EDI�Q�EBX�Q�EBP寄存器，退出函数时则��生代码恢复这些寄存器的内宏V��naked call不��生这��L��代码。naked call不是�c�d��修饰�W�，故必��d��_declspec共同使用�?/p>

关键�?__stdcall、__cdecl �?__fastcall 可以直接加在要输出的函数前，也可以在�~�译环境�?Setting...\C/C++ \Code Generation ��w��择。当加在输出函数前的关键字与�~�译环境中的选择不同�Ӟ��直接加在输出函数前的关键字有效。它们对应的命��o行参数分别�ؓ/Gz�?Gd �?/Gr。缺省状态�ؓ/Gd�Q�即__cdecl。缺省状态�ؓ__cdecl�?/p>

4. �? 字修饰约�?/strong>

"C" 或�?"C++" 函数在内部（�~�译和链接）通过修饰名识别。修饰名是编译器在编�? 函数定义或者原型时生成的字�W�串。有些情况下使用函数的修饰名是必要的�Q�如在模块定义文仉��头指定输�?C++"重蝲函数、构造函数、析构函敎ͼ�又如在汇�~�代码里调用"C""�?C++"函数�{�。修饰名由函数名、类名、调用约定、返回类型、参数等共同军_��。函数名修饰�U�定随编译种�c?C或C++)和调用约定的不同而不同，下面分别说明�?/p>

C�~�译时函数名修饰�U�定规则�Q?/p>
__stdcall调用�U�定�Q?/p>
    在输出函数名前加上一个下划线前缀�Q�后面加上一�?@"�W�号和其参数的字节数�Q�格式�ؓ _functionname@number�?/p>

__cdecl调用�U�定�Q?/p>
   仅在输出函数名前加上一个下划线前缀�Q�格式�ؓ _functionname�?/p>

__fastcall调用�U�定�Q?/p>
    在输出函数名前加上一�?@"�W�号�Q�后面也是一�?@"�W�号和其参数的字节数�Q�格式�ؓ@functionname@number�?/p>

它们均不改变输出函数名中的字�W�大��写�?/p>

C++�~�译时函数名修饰�U�定规则�Q?/p>
__stdcall调用�U�定�Q?/p>
�??"标识函数名的开始，后跟函数名；函数名后面以"@@YG"标识参数表的开始，后跟参数表；

参数表以代号表示�Q?/p>
    X——void�Q?/p>
    D——char�Q?/p>
    E——unsigned char�Q?/p>
    F——short�Q?/p>
    H——int�Q?/p>
    I——unsigned int�Q?/p>
    J——long�Q?/p>
    K——unsigned long�Q?/p>
    M——float�Q?/p>
    N——double�Q?/p>
    _N——bool�Q?/p>
    ....

    PA——表�C�指针，后面的代可��明指针类型，如果相同�c�d��的指针连�l�出玎ͼ� �?0"代替�Q�一�?0"代表一�ơ重复；

参数表的�W�一��ؓ该函数的�q�回值类型，其后依次为参数的数据�c�d��,指针标识在其所指数据类型前�?/p>
参数表后�?@Z"标识整个名字的结束，如果该函数无参数�Q�则�?Z"标识�l�束。其格式�?/p>
    "?functionname@@YG*****@Z" �? "?functionname@@YG*XZ"�Q?/p>
    例如

    int Test1(char *var1,unsigned long)    -----“?Test1@@YGHPADK@Z”

    void Test2()　　　　　　　　　　　   -----“?Test2@@YGXXZ”(�W�一个X表示�q�回�c�d��Q�第二个X表示参数 �c�d��)

__cdecl调用�U�定�Q?/p>
    规则同上面的_stdcall调用�U�定�Q�只是参数表的开始标识由上面�?@@YG"变�ؓ"@@YA"。VC++对函数的省缺声明�?__cedcl"�Q�将只能被C/C++调用�?/p>

__fastcall调用�U�定�Q?/p>
    规则同上面的_stdcall调用�U�定�Q�只是参数表的开始标识由上面�?@@YG"变�ؓ"@@YI"�?/p>

对于C++的类成员函数�Q�其调用方式是thiscall�Q�，函数的名字修��C��非成员的C++函数�E�有不同�Q�首先就是在函数名字和参数表之间插入�?#8220;@”字符引导的类名；其次是参数表的开始标识不同，公有�Q�public�Q�成员函数的标识�?#8220;@@QAE”,保护�Q�protected�Q�成员函数的标识�?#8220;@@IAE”,�U�有�Q�private�Q�成员函数的标识�?#8220;@@AAE”�Q�如果函数声明��用了const关键字，则相应的标识应分别�ؓ“@@QBE”�Q?#8220;@@IBE”�?#8220;@@ABE”。如果参数类型是�c�d��例的引用�Q�则使用“AAV1”�Q�对于const�c�d��的引用，则��?#8220;ABV1”。下面就以类CTest��Z��说明C++成员函数的名字修饰规则：

class CTest

{

......

private:

    void Function(int);

protected:

    void CopyInfo(const CTest &src);

public:

    long DrawText(HDC hdc, long pos, const TCHAR* text, RGBQUAD color, BYTE bUnder, bool bSet);

  long InsightClass(DWORD dwClass) const;

......

};

对于成员函数Function�Q�其函数修饰名�ؓ“?Function@CTest@@AAEXH@Z”�Q�字�W�串“@@AAE”表示�q�是一个私有函数�?#8220;X”表示�q�回�c�d��为void�Q?#8220;H”表示参数�c�d��为int�c�d��?/p>

成员函数CopyInfo只有一个参敎ͼ�是对�c�CTest的const引用参数�Q�其函数修饰名�ؓ“?CopyInfo@CTest@@IAEXABV1@@Z”�?/p>

DrawText是一个比较复杂的函数声明�Q�不仅有字符串参敎ͼ��q�有�l�构体参数和HDC句柄参数�Q�需要指出的是HDC实际上是一个HDC__�l�构�c�d��的指针，�q�个参数的表�C�就�?#8220;PAUHDC__@@”�Q�其完整的函��C��饰名�?#8220;?DrawText@CTest@@QAEJPAUHDC__@@JPBDUtagRGBQUAD@@E_N@Z”�?/p>

InsightClass是一个共有的const函数�Q�它的成员函数标识是“@@QBE”�Q�完整的修饰名就�?#8220;?InsightClass@CTest@@QBEJK@Z”�?/p>

举例�Q?/p>
比如动态链接库a有以下导出函敎ͼ�

long MakeFun(long lFun);

动态库生成的时候采用的函数调用�U�定是__stdcall�Q�所以编译生成的a.dll中函数MakeFun的调用约定是_stdcall�Q�也��是函数调用时参��C��叛_��左入栈，函数�q�回时自��p��原堆栈。现在某个程序模块b要引用a中的MakeFun�Q�b和a一样��用C++方式�~�译�Q�只是b模块的函数调用方式是__cdecl�Q�由于b包含了a提供的头文�g中MakeFun函数声明�Q�所以MakeFun在b模块中被其它调用MakeFun的函数认为是__cdecl调用方式�Q�b模块中的 �q�些函数在调用完MakeFun当然要帮着恢复堆栈啦，可是MakeFun已经在结束时自己恢复了堆栈，b模块中的函数�q�样多此一丑ְ�引�v了栈指针错误�Q�从而引发堆栈异常。宏观上的现象就是函数调用没有问题（因�ؓ参数传�? ��序是一��L��Q�，MakeFun也完成了自己的功能，只是函数�q�回后引发错误。解决的�Ҏ��也很��单，只要保证两个模块的在�~�译时设�|�相同的函数调用�U�定��p��了�?/p>

现在再假定两个模块在�~�译的时候都采用__stdcall调用�U�定�Q�但是a.dll使用C语言的语法编译的(C语言方式)�Q�所以a.dll�? 载入库a.lib中MakeFun函数的名字修饰就�?#8220;_MakeFun@4”。b包含了a提供的头文�g中MakeFun函数声明�Q�但是由于b采用的是C++语言�~�译�Q�所以MakeFun在b模块中被按照C++的名字修饰规则命名�ؓ“?MakeFun@@YGJJ@Z”�Q�编译过�E�相安无事，链接�E�序时c++的链接器��到a.lib中去�?#8220;?MakeFun@@YGJJ@Z”�Q�但是a.lib中只�?#8220;_MakeFun@4”�Q�没�?#8220;?MakeFun@@YGJJ@Z”�Q�于是链接器��报告：

error LNK2001: unresolved external symbol ?MakeFun@@YGJJ@Z

解决的方法和��单，��是要让b模块知道�q�个函数是C语言�~�译的，extern "C"可以做到�q�一炏V��一个采用C语言�~�译的库应该考虑��C��用这个库的程序可能是C++�E�序�Q��用C++�~�译器）�Q�所以在设计头文件时应该注意�q�一炏V��通常应该�q�样声明头文�Ӟ��

#ifdef _cplusplus

extern "C" {

#endif

long MakeFun(long lFun);

#ifdef _cplusplus

}

#endif

�q�样C++的编译器��q��道MakeFun的修饰名�?#8220;_MakeFun@4”�Q�就不会有链接错误了�?/p>

许多��Z��明白�Q��ؓ什么我使用的编译器都是VC的编译器�q�会产生“error LNK2001”错误�Q�其实，VC的编译器会根据源文�g的扩展名选择�~�译方式�Q�如果文件的扩展名是“.C”�Q�编译器会采用C的语法编译，如果扩展名是“.cpp”�Q�编译器会��用C++的语法编译程序，所以，最好的�Ҏ��是使用extern "C"�?/p>

5. 单看函数的名字修�?/strong>
有两�U�方式可以检查你的程序中的函数的名字修饰�Q��用编译输出列表或使用Dumpbin工具。��?FAc�Q?FAs�?FAcs命��o行参数可以让�~�译器输出函数或变量名字列表。��用dumpbin.exe /SYMBOLS命��o也可以获得obj文�g或lib文�g中的函数或变量名字列表。此外，�q�可以��?undname.exe ��修饰名转换为未修饰形式�?

from:
http://patmusing.blog.163.com/blog/static/13583496020103233446784/

chatler 2010-04-28 00:10 发表评论

An In-Depth Look into the Win32 Portable Executable File Format

chatler — Thu, 25 Mar 2010 07:17:00 GMT
     摘要: from: http://msdn.microsoft.com/zh-cn/magazine/cc301808%28en-us%29.aspx Download the code for this article: PE.exe (98KB) part1: SUMMARY A good understanding of the Portable Executable (PE) fi...  阅读全文

chatler 2010-03-25 15:17 发表评论

chatler — Mon, 04 Jan 2010 07:21:00 GMT
异步IO、APC、IO完成端口、线�E�池与高性能服务�?/span>
异步IO、APC、IO完成端口、线�E�池与高性能服务器之一异步IO

背景�Q�轮�?PIO DMA 中断

   早期IO讑֤�的速度与CPU相比�Q�还不是太悬�D�。CPU定时轮询一遍IO讑֤��Q�看看有无处理要求，有则加以处理�Q�完成后�q�回�l�箋工作。至今，软盘驱动器还保留着�q�种轮询工作方式�?/div>
   �?着CPU性能的迅速提高，�q�种效率低下的工作方式浪费了大量的CPU旉��。因此，中断工作方式开始成为普遍采用的技术。这�U�技术��得IO讑֤�在需要得到服务时�Q�能够��生一个硬件中断，�q��CPU攑ּ�目前的处理�Q务，�q�入特定的中断服务过�E�，中断服务完成后，再��l�原先的处理。这样一来，IO讑֤�和CPU�?以同时进行处理，从而避免了CPU�{�待IO完成�?/div>
   早期数据的传输方式主要是PIO�Q�程控IO�Q�方式。通过对IO地址�~�程方式的方式来传输数据。比如串行口�Q��Y件每�ơ往串行口上写一个字节数据，串口讑֤�完成传输��d��后，��会产生一个中断，然后软�g再次重复直到全部数据发送完成。性能更好的硬件设备提供一个FIFO�Q�先�q�先出缓冲部�Ӟ��Q�可以让软�g一�ơ传输更多的字节�?/div>
   昄��Q��用PIO方式对于高速IO讑֤�来说�Q�还是占用了�?多的CPU旉��Q�因为需要通过CPU�~�程控制传输�Q�。而DMA�Q�直接内存访问）方式能够极大地减��CPU处理旉��。CPU仅需告诉DMA控制器数据块的�v 始地址和大��，以后DMA控制器就可以自行在内存和讑֤�之间传输数据�Q�其间CPU可以处理其他��d��。数据传输完毕后��会产生一个中断�?/div>

同步文�gIO和异步文件IO

下面摘抄于MSDN《synchronous file I/O and asynchronous file I/O》�?/div>
有两�U�类型的文�gIO同步�Q�同步文件IO和异步文件IO。异步文件IO也就是重叠IO�?/div>
在同步文件IO中，�U�程启动一个IO操作然后��q��卌��入等待状态，直到IO操作完成后才醒来�l�箋执行。而异步文件IO方式中，�U�程发送一个IO��h��到内核，然后�l�箋处理其他的事情，内核完成IO��h��后，��会通知�U�程IO操作完成了�?/div>

如果IO��h��需要大量时间执行的话，异步文�gIO方式可以显著提高效率�Q�因为在�U�程�{�待的这�D�|��间内�Q�CPU��会调度其他�U�程�q�行执行�Q�如果没有其他线�E�需要执行的话，�q�段旉��会��费掉（可能会调度操作系�l�的雉��U�程�Q�。如果IO��h��操作很快�Q�用异步IO方式反而还低效�Q�还不如用同步IO�?式�?/div>
   同步IO在同一时刻只允�怸�个IO操作�Q�也��是说对于同一个文件句柄的IO操作是序列化的，即��使用两个�U�程也不能同时对同一个文件句柄同时发��写操作。重叠IO允许一个或多个�U�程同时发出IO��h��?/div>
   异步IO在请求完成时�Q�通过��文件句柄设为有信号状态来通知应用�E�序�Q�或者应用程序通过GetOverlappedResult察看IO��h��是否完成�Q�也可以通过一个事件对象来通知应用�E�序�?/div>

参考书�?/div>

1�Q? MSDN Library
2�Q? 《Windows高��~�程指南�?/div>
3�Q? 《Windows核心�~�程�?/div>
4�Q? 《Windows 2000 讑֤�驱动�E�序设计指南�?/div>

异步IO、APC、IO完成端口、线�E�池与高性能服务器之�?APC

   Alertable IO(告警IO)提供了更有效的异步通知形式。ReadFileEx / WriteFileEx在发出IO��h��的同�Ӟ��提供一个回调函敎ͼ�APC�q�程�Q�，当IO��h��完成后，一旦线�E�进入可告警状态，回调函数��会执行�?/div>
   以下五个函数能够使线�E�进入告警状态：
   SleepEx
   WaitForSingleObjectEx
   WaitForMultipleObjectsEx
   SignalObjectAndWait
   MsgWaitForMultipleObjectsEx
   �U?�E�进入告警状态时�Q�内核将会检查线�E�的APC队列�Q�如果队列中有APC�Q�将会按FIFO方式依次执行。如果队列�ؓ�I�，�U�程��会挂�v�{�待事�g对象。以后的�?个时刻，一旦APC�q�入队列�Q�线�E�将会被唤醒执行APC�Q�同时等待函数返回WAIT_IO_COMPLETION�?/div>
   QueueUserAPC可以用来��Zؓ投递APC�Q�只要目标线�E�处于告警状态时�Q�APC��p��够得到执行�?/div>
   使用告警IO的主要缺�Ҏ��发出IO��h��的线�E�也必须是处理结果的�U�程�Q�如果一个线�E�退出时�q�有未完成的IO��h��Q�那么应用程序将永远丢失IO完成通知。然而以后我们将会看到IO完成端口没有�q�个限制�?/div>
   下面的代码演�C�Z��QueueUserAPC的用法�?/div>

/************************************************************************/
/* APC Test. */
/************************************************************************/

DWORD WINAPI WorkThread(PVOID pParam)
{
   HANDLE Event = (HANDLE)pParam;

   for(;;)
   {
   DWORD dwRet = WaitForSingleObjectEx(Event, INFINITE, TRUE);
   if(dwRet == WAIT_OBJECT_0)
   break;
   else if(dwRet == WAIT_IO_COMPLETION)
   printf("WAIT_IO_COMPLETION\n");
   }

   return 0;
}

VOID CALLBACK APCProc(DWORD dwParam)
{
   printf("%s", (PVOID)dwParam);
}

void TestAPC(BOOL bFast)
{
   HANDLE QuitEvent = CreateEvent(NULL, FALSE, FALSE, NULL);

   HANDLE hThread = CreateThread(NULL,
   0,
   WorkThread,
   (PVOID)QuitEvent,
   0,
   NULL);

   Sleep(100); // Wait for WorkThread initialized.

   for(int i=5; i>0; i--)
   {
   QueueUserAPC(APCProc, hThread, (DWORD)(PVOID)"APC here\n");

   if(!bFast)
   Sleep(1000);
   }

   SetEvent(QuitEvent);
   WaitForSingleObject(hThread, INFINITE);
   CloseHandle(hThread);
}

参考书�?/div>

1�Q? MSDN Library
2�Q? 《Windows高��~�程指南�?/div>
3�Q? 《Windows核心�~�程�?/div>
4�Q? 《Windows 2000 讑֤�驱动�E�序设计指南�?/div>

异步IO、APC、IO完成端口、线�E�池与高性能服务器之�?IO完成端口

IO完成端口

下面摘抄于MSDN《I/O Completion Ports》，smallfool��译�Q�原文请参考CSDN文档中心文章《I/O Completion Ports》， http://dev.csdn.net/Develop/article/29%5C29240.shtm �?/div>
I/O 完成端口是一�U�机�Ӟ��通过�q�个机制�Q�应用程序在启动时会首先创徏一个线�E�池�Q�然后该应用�E�序使用�U�程池处理异步I/O��h��。这些线�E�被创徏的唯一目的��是用于处理I/O��h��。对于处理大量�ƈ发异步I/O��h��的应用程序来��_��相比于在I/O��h��发生时创建线�E�来��_��使用完成端口(s)它就可以做的更快且更�?效率�?/div>
CreateIoCompletionPort函数会��一个I/O完成端口与一个或多个文�g句柄发生兌��。当与一个完成端口相关的文�g句柄上启动的异步I/O操作完成�Ӟ��一个I/O完成包就会进入到该完成端口的队列中。对于多个文件句柄来��_��q�种机制可以用来把多文�g句柄的同步点攑֜�单个�?象中。（�a�下之意，如果我们需要对每个句柄文�g�q�行同步�Q�一般而言我们需要多个对象（如：Event来同步）�Q�而我们��用IO Complete Port 来实现异步操作，我们可以同多个文件相兌��Q�每当一个文件中的异步操作完成，��׃��把一个complete package攑ֈ�队列中，�q�样我们��可以��用这个来完成所有文件句柄的同步�Q?/div>
调用GetQueuedCompletionStatus函数�Q�某个线�E�就会等待一个完成包�q�入到完成端口的队列中，而不是直接等待异步I/O��h��完成。线�E�（们）��׃��d��于它们的�q�行在完成端口（按照后进先出队列��序的被释放�Q�。这��意味着当一个完成包�q�入到完成端口的队列中时�Q�系�l�会释放最�q�被��d��在该完成端口的线�E��?/div>
调用GetQueuedCompletionStatus�Q�线�E�就会将会与某个指定的完成端口徏立联�p�，一直�g�l�其该线�E�的存在周期�Q�或被指定了不同的完成端口，或者释放了与完成端口的联系。一个线�E�只能与最多不��过一个的完成端口发生联系�?/div>
�?成端口最重要的特性就是�ƈ发量。完成端口的�q�发量可以在创徏该完成端口时指定。该�q�发量限制了与该完成端口相关联的可运行线�E�的数目。当与该完成端口相关联的可运行线�E�的��L��目达��C��该�ƈ发量�Q�系�l�就会阻塞�Q何与该完成端口相兌��的后�l�线�E�的执行�Q�直��C��该完成端口相兌��的可�q�行�U�程数目下降到小于该�q�发量�ؓ止。最有效的假��x��发生在有完成包在队列中等待，而没有等待被满��Q�因为此时完成端口达��C��其�ƈ发量的极限。此�Ӟ��一个正在运行中的线�E�调�?GetQueuedCompletionStatus�Ӟ��它就会立��M��队列中取走该完成包。这样就不存在着环境的切换，因�ؓ该处于运行中的线�E�就会连�l�不断地从队列中取走完成包，而其他的�U�程��׃��能运行了�?/div>
对于�q�发量最好的挑选值就是您计算��Z��CPU的数目。如果您的事务处理需要一个�O长的计算旉��Q�一个比较大的�ƈ发量可以允许更多�U�程来运行。虽然完成每个事务处理需要花�Ҏ��长的旉��Q�但更多的事务可以同时被处理。对于应用程序来��_��很容易通过��试�q�发量来获得最好的效果�?/div>
PostQueuedCompletionStatus函数允许应用�E�序可以针对自定义的专用I/O完成包进行排队，而无需启动一个异步I/O操作。这点对于通知外部事�g的工作者线�E�来说很有用�?/div>
在没有更多的引用针对某个完成端口�Ӟ��需要释放该完成端口。该完成端口句柄以及与该完成端口相关联的所有文件句柄都需要被释放。调用CloseHandle可以释放完成端口的句柄�?/div>

下面的代码利用IO完成端口做了一个简单的�U�程池�?/div>

/************************************************************************/
/* Test IOCompletePort. */
/************************************************************************/

DWORD WINAPI IOCPWorkThread(PVOID pParam)
{
   HANDLE CompletePort = (HANDLE)pParam;
   PVOID UserParam;
   WORK_ITEM_PROC UserProc;
   LPOVERLAPPED pOverlapped;

   for(;;)
   {
   BOOL bRet = GetQueuedCompletionStatus(
   CompletePort,
   (LPDWORD)&UserParam,
   (LPDWORD)&UserProc,
   &pOverlapped,
   INFINITE);

   _ASSERT(bRet);

   if(UserProc == NULL) // Quit signal.
   break;

   // execute user's proc.
   UserProc(UserParam);
   }

   return 0;
}

void TestIOCompletePort(BOOL bWaitMode, LONG ThreadNum)
{
   HANDLE CompletePort;
   OVERLAPPED Overlapped = {0, 0, 0, 0, NULL};

   CompletePort = CreateIoCompletionPort(
   INVALID_HANDLE_VALUE,
   NULL,
   NULL,
   0);

   // Create threads.
   for(int i=0; i
   {
   HANDLE hThread = CreateThread(NULL,
   0,
   IOCPWorkThread,
   CompletePort,
   0,
   NULL);

   CloseHandle(hThread);
   }

   CompleteEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
   BeginTime = GetTickCount();
   ItemCount = 20;

   for(i=0; i<20; i++)
   {
   PostQueuedCompletionStatus(
   CompletePort,
   (DWORD)bWaitMode,
   (DWORD)UserProc1,
   &Overlapped);
   }

   WaitForSingleObject(CompleteEvent, INFINITE);
   CloseHandle(CompleteEvent);

   // Destroy all threads.
   for(i=0; i
   {
   PostQueuedCompletionStatus(
   CompletePort,
   NULL,
   NULL,
   &Overlapped);
   }

   Sleep(1000); // wait all thread exit.

   CloseHandle(CompletePort);
}

参考书�?/div>

1�Q? MSDN Library
2�Q? 《Windows高��~�程指南�?/div>
3�Q? 《Windows核心�~�程�?/div>
4�Q? 《Windows 2000 讑֤�驱动�E�序设计指南�?/div>

异步IO、APC、IO完成端口、线�E�池与高性能服务器之�?�U�程�?/div>

�U�程�?/div>

下面摘抄于MSDN《Thread Pooling》�?/div>
�?许多应用�E�序创徏的线�E�花费了大量旉��在睡眠状态来�{�待事�g的发生。还有一些线�E�进入睡眠状态后定期被唤醒以轮询工作方式来改变或者更新状态信息。线�E�池可以让你更有效地使用�U�程�Q�它��Z��的应用程序提供一个由�pȝ��理的工作者线�E�池。至��会有一个线�E�来监听攑ֈ��U�程池的所有等待操作，当等待操作完成后�Q�线 �E�池中将会有一个工作者线�E�来执行相应的回调函数�?/div>
你也可以把没有等待操作的工作��目攑ֈ��U�程池中�Q�用QueueUserWorkItem函数来完成这个工作，把要执行的工作项目函数通过一个参��C��递给�U�程池。工作项目被攑ֈ��U�程池中后，��׃��能再取消了�?/div>
Timer-queue timers和Registered wait operations也��用线�E�池来实现。他们的回调函数也放在线�E�池中。你也可以用BindIOCompletionCallback函数来投递一个异步IO操作�Q�在IO完成端口上，回调函数也是��q��E�池�U�程来执行�?/div>
当第一�ơ调用QueueUserWorkItem函数或�?BindIOCompletionCallback函数的时候，�U�程池被自动创徏�Q�或者Timer-queue timers或者Registered wait operations攑օ�回调函数的时候，�U�程池也可以被创建。线�E�池可以创徏的线�E�数量不限，仅受限于可用的内存，每一个线�E��用默认的初始堆栈大小�Q?�q�行在默认的优先�U�上�?/div>
�U�程池中有两�U�类型的�U�程�Q�IO�U�程和非IO�U�程。IO�U�程�{�待在可告警状态，工作��目作�ؓAPC攑ֈ�IO�U�程中。如果你的工作项目需要线�E�执行在可警告状态，你应该将它放到IO�U�程�?/div>
非IO工作者线�E�等待在IO完成端口上，使用非IO�U�程比IO�U�程效率更高�Q�也��是��_��只要有可能的话，��量使用非IO�U�程。IO�U�程和非IO�U�程在异步IO操作没有完成之前都不会退出。然而，不要在非IO�U�程中发出需要很长时间才能完成的异步IO��h��?/div>
�?��用线�E�池的方法是�Q�工作项目函��C��及它��会调用到的所有函数都必须是线�E�池安全的。安全的函数不应该假讄��E�是一�ơ性线�E�的或者是�怹��U�程。一般来 ��_��应该避免使用�U�程本地存储和发出需要永久线�E�的异步IO调用�Q�比如说RegNotifyChangeKeyValue函数。如果需要在�怹��U�程中执�?�q�样的函数的话，可以�l�QueueUserWorkItem传递一个选项WT_EXECUTEINPERSISTENTTHREAD�?/div>
注意�Q�线�E�池不能兼容COM的单�U�程套间�Q�STA�Q�模型�?/div>

   ��Z��更深入地讲解操作�pȝ��实现的线�E�池的优��性，我们首先��试着自己实现一个简单的�U�程池模型�?/div>

   代码如下�Q?/div>

/************************************************************************/
/* Test Our own thread pool. */
/************************************************************************/

typedef struct _THREAD_POOL
{
   HANDLE QuitEvent;
   HANDLE WorkItemSemaphore;

   LONG WorkItemCount;
   LIST_ENTRY WorkItemHeader;
   CRITICAL_SECTION WorkItemLock;

   LONG ThreadNum;
   HANDLE *ThreadsArray;

}THREAD_POOL, *PTHREAD_POOL;

typedef VOID (*WORK_ITEM_PROC)(PVOID Param);

typedef struct _WORK_ITEM
{
   LIST_ENTRY List;

   WORK_ITEM_PROC UserProc;
   PVOID UserParam;

}WORK_ITEM, *PWORK_ITEM;

DWORD WINAPI WorkerThread(PVOID pParam)
{
   PTHREAD_POOL pThreadPool = (PTHREAD_POOL)pParam;
   HANDLE Events[2];

   Events[0] = pThreadPool->QuitEvent;
   Events[1] = pThreadPool->WorkItemSemaphore;

   for(;;)
   {
   DWORD dwRet = WaitForMultipleObjects(2, Events, FALSE, INFINITE);

   if(dwRet == WAIT_OBJECT_0)
   break;

   //
   // execute user's proc.
   //

   else if(dwRet == WAIT_OBJECT_0 +1)
   {
   PWORK_ITEM pWorkItem;
   PLIST_ENTRY pList;

   EnterCriticalSection(&pThreadPool->WorkItemLock);
   _ASSERT(!IsListEmpty(&pThreadPool->WorkItemHeader));
   pList = RemoveHeadList(&pThreadPool->WorkItemHeader);
   LeaveCriticalSection(&pThreadPool->WorkItemLock);

   pWorkItem = CONTAINING_RECORD(pList, WORK_ITEM, List);
   pWorkItem->UserProc(pWorkItem->UserParam);

   InterlockedDecrement(&pThreadPool->WorkItemCount);
   free(pWorkItem);
   }

   else
   {
   _ASSERT(0);
   break;
   }
   }

   return 0;
}

BOOL InitializeThreadPool(PTHREAD_POOL pThreadPool, LONG ThreadNum)
{
   pThreadPool->QuitEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
   pThreadPool->WorkItemSemaphore = CreateSemaphore(NULL, 0, 0x7FFFFFFF, NULL);
   pThreadPool->WorkItemCount = 0;
   InitializeListHead(&pThreadPool->WorkItemHeader);
   InitializeCriticalSection(&pThreadPool->WorkItemLock);
   pThreadPool->ThreadNum = ThreadNum;
   pThreadPool->ThreadsArray = (HANDLE*)malloc(sizeof(HANDLE) * ThreadNum);

   for(int i=0; i
   {
   pThreadPool->ThreadsArray[i] = CreateThread(NULL, 0, WorkerThread, pThreadPool, 0, NULL);
   }

   return TRUE;
}

VOID DestroyThreadPool(PTHREAD_POOL pThreadPool)
{
   SetEvent(pThreadPool->QuitEvent);

   for(int i=0; iThreadNum; i++)
   {
   WaitForSingleObject(pThreadPool->ThreadsArray[i], INFINITE);
   CloseHandle(pThreadPool->ThreadsArray[i]);
   }

   free(pThreadPool->ThreadsArray);

   CloseHandle(pThreadPool->QuitEvent);
   CloseHandle(pThreadPool->WorkItemSemaphore);
   DeleteCriticalSection(&pThreadPool->WorkItemLock);

   while(!IsListEmpty(&pThreadPool->WorkItemHeader))
   {
   PWORK_ITEM pWorkItem;
   PLIST_ENTRY pList;

   pList = RemoveHeadList(&pThreadPool->WorkItemHeader);
   pWorkItem = CONTAINING_RECORD(pList, WORK_ITEM, List);

   free(pWorkItem);
   }
}

BOOL PostWorkItem(PTHREAD_POOL pThreadPool, WORK_ITEM_PROC UserProc, PVOID UserParam)
{
   PWORK_ITEM pWorkItem = (PWORK_ITEM)malloc(sizeof(WORK_ITEM));
   if(pWorkItem == NULL)
   return FALSE;

   pWorkItem->UserProc = UserProc;
   pWorkItem->UserParam = UserParam;

   EnterCriticalSection(&pThreadPool->WorkItemLock);
   InsertTailList(&pThreadPool->WorkItemHeader, &pWorkItem->List);
   LeaveCriticalSection(&pThreadPool->WorkItemLock);

   InterlockedIncrement(&pThreadPool->WorkItemCount);

   ReleaseSemaphore(pThreadPool->WorkItemSemaphore, 1, NULL);

   return TRUE;
}

VOID UserProc1(PVOID dwParam)
{
   WorkItem(dwParam);
}

void TestSimpleThreadPool(BOOL bWaitMode, LONG ThreadNum)
{
   THREAD_POOL ThreadPool;
   InitializeThreadPool(&ThreadPool, ThreadNum);

   CompleteEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
   BeginTime = GetTickCount();
   ItemCount = 20;

   for(int i=0; i<20; i++)
   {
   PostWorkItem(&ThreadPool, UserProc1, (PVOID)bWaitMode);
   }

   WaitForSingleObject(CompleteEvent, INFINITE);
   CloseHandle(CompleteEvent);

   DestroyThreadPool(&ThreadPool);
}
   我们把工作项目放��C��个队列中�Q�用一个信号量通知�U�程池，�U�程池中��L��一个线�E�取出工作项目来执行�Q�执行完毕之后，�U�程�q�回�U�程池，�l�箋�{�待新的工作��目�?/div>
   �U�程池中�U�程的数量是固定的，预先创徏好的�Q�永久的�U�程�Q�直到销毁线�E�池的时候，�q�些�U�程才会被销毁�?/div>
   �U�程池中�U�程获得工作��目的机会是均等的，随机的，�q�没有特别的方式保证哪一个线�E�具有特�D�的优先获得工作��目的机会�?/div>
   而且�Q�同一时刻可以�q�发�q�行的线�E�数目没有�Q何限定。事实上�Q�在我们的执行计��Q务的演示代码中，所有的�U�程都�ƈ发执行�?/div>
   下面�Q�我们再来看一下，完成同样的�Q务，�pȝ��提供的线�E�池是如何运作的�?/div>

/************************************************************************/
/* QueueWorkItem Test. */
/************************************************************************/

DWORD BeginTime;
LONG ItemCount;
HANDLE CompleteEvent;

int compute()
{
   srand(BeginTime);

   for(int i=0; i<20 *1000 * 1000; i++)
   rand();

   return rand();
}

DWORD WINAPI WorkItem(LPVOID lpParameter)
{
   BOOL bWaitMode = (BOOL)lpParameter;

   if(bWaitMode)
   Sleep(1000);
   else
   compute();

   if(InterlockedDecrement(&ItemCount) == 0)
   {
   printf("Time total %d second.\n", GetTickCount() - BeginTime);
   SetEvent(CompleteEvent);
   }

   return 0;
}

void TestWorkItem(BOOL bWaitMode, DWORD Flag)
{
   CompleteEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
   BeginTime = GetTickCount();
   ItemCount = 20;

   for(int i=0; i<20; i++)
   {
   QueueUserWorkItem(WorkItem, (PVOID)bWaitMode, Flag);
   }

   WaitForSingleObject(CompleteEvent, INFINITE);
   CloseHandle(CompleteEvent);
}
   很简单，是吧�Q�我们仅需要关注于我们的回调函数即可。但是与我们的简单模拟来比，�pȝ��提供的线�E�池有着更多的优炏V�?/div>
   首先�Q�线�E�池中线�E�的数目是动态调整的�Q�其�ơ，�U�程池利用IO完成端口的特性，它可以限制�ƈ发运行的�U�程数目�Q�默认情况下�Q�将会限制�ؓCPU的数目，�q�可以减��线�E�切换。它挑选最�q�执行过的线�E�再�ơ投入执行，从而避免了不必要的�U�程切换�?/div>
   �pȝ��提供的线�E�池背后的策略，我们下一节��l�再谈�?/div>

参考书�?/div>

1�Q? MSDN Library
2�Q? 《Windows高��~�程指南�?/div>
3�Q? 《Windows核心�~�程�?/div>
4�Q? 《Windows 2000 讑֤�驱动�E�序设计指南�?/div>

正文
异步IO、APC、IO完成端口、线�E�池与高性能服务器之�?服务器的性能指标与实现高性能的途径

服务器的性能指标

   作�ؓ一个网�l�服务器�E�序�Q�性能永远是第一位的指标。性能可以�q�样定义�Q�在�l�定的硬件条件和旉��里，能够处理的�Q务量。能够最大限度地利用��g性能的服务器设计才是良好的设计�?/div>
   设计良好的服务器�q�应该考虑�q�_��服务�Q�对于每一个客��L��Q�服务器应该�l�予每个客户端��^均的服务�Q�不能让某一个客��L��长时间得不到服务而发�?#8220;饥饿”的状��c�?/div>
   可�׾~�性，也就是说�Q�随着��g能力的提高，服务器的性能能够随之呈线性增�ѝ�?/div>

实现高性能的途径

   一个实际的服务器的计算是很复杂的，往往是�؜合了IO计算和CPU计算。IO计算指计��Q务中以IO��Z��的计��模型，比如文�g服务器、邮件服务器�{�，混合�?大量的网�l�IO和文件IO�Q�CPU计算指计��Q务中没有或很��有IO�Q�比如加�?解密�Q�编�?解码�Q�数学计��等�{��?/div>
   在CPU计算中，单线 �E�和多线�E�模型效果是相当的。《Win32多线�E�的性能》中�?#8220;在一个单处理器的计算��Z��Q�基�?CPU 的�Q务的�q�发执行速度不可能比串行执行速度快，但是我们可以看到�Q�在 Windows NT 下线�E�创建和切换的额外开销非常��；对于非常短的计算�Q��ƈ发执行仅仅比串行执行�?10%�Q�而随着计算长度的增加，�q�两个时间就非常接近了�?#8221;
   可见�Q�对于纯�_�的CPU计算来说�Q�如果只有一个CPU�Q�多�U�程模型是不合适的。考虑一个执行密集的CPU计算的服务，如果有几十个�q�样的线�E��ƈ发执行，�q�于频繁��C�Q务切换导致了不必要的性能损失�?/div>
   �?�~�程实现上，单线�E�模型计��模型对于服务器�E�序设计是很不方便的。因此，对于CPU计算采用�U�程池工作模型是比较恰当的�?QueueUserWorkItem函数非常适合于将一个CPU计算攑օ��U�程池。线�E�池实现��会努力减少�q�种不必要的�U�程切换�Q�而且控制�q�发�U�程的数目�ؓ CPU的数目�?/div>
   我们真正需要关心的是IO计算�Q�一般的�|�络服务器程序往往伴随着大量的IO计算。提高性能的途径在于要避免等待IO 的结束，造成CPU�I�闲�Q�要��量利用��g能力�Q�让一个或多个IO讑֤�与CPU�q�发执行。前面介�l�的异步IO�Q�APC�Q�IO完成端口都可以达到这个目的�?/div>
   �?于网�l�服务器来说�Q�如果客��L��q�发��h��数目比较��的话，用简单的多线�E�模型就可以应付了。如果一个线�E�因为等待IO操作完成而被挂�v�Q�操作系�l�将会调度另外一个就�l�的�U�程投入�q�行�Q�从而�Ş成�ƈ发执行。经典的�|�络服务器逻辑大多采用多线�E?多进�E�方式，在一个客��L��发�v到服务器的连接时�Q�服务器��会创徏一�?�U�程�Q�让�q�个新的�U�程来处理后�l�事务。这�U�以一个专门的�U�程/�q�程来代表一个客��L��对象的编�E�方法非常直观，易于理解�?/div>
   对于大型�|�络服务器程序来��_��q�种方式存在着局限性。首先，创徏�U�程/�q�程和销毁线�E?�q�程的代价非帔R��昂，��其是在服务器采用TCP“短连�?#8221;方式或UDP方式通讯的情况下�Q�例如，HTTP协议中，客户端发起一个连接后�Q�发送一个请求，服务器回应了�q�个��h��后，�q�接也就被关闭了。如果采用经典方式设计HTTP服务器，�?么过于频�J�地创徏�U�程/销毁线�E�对性能造成的媄响是很恶劣的�?/div>
   其次�Q�即使一个协议中采取TCP“长连�?#8221;�Q�客��L��q�上服务器后��׃��直保�?此连接，�l�典的设计方式也是有弊病的。如果客��L��q�发��h��量很高，同一时刻有很多客��L��{�待服务器响应的情况下，��会有过多的�U�程�q�发执行�Q�频�J�的�U�程�?换将用掉一部分计算能力。实际上�Q�如果�ƈ发线�E�数目过多的话，往往会过早地耗尽物理内存�Q�绝大部分时间耗费在线�E�切换上�Q�因为线�E�切换的同时也将引�v内存调页。最�l�导致服务器性能急剧下降�Q?/div>
   对于一个需要应付同时有大量客户端�ƈ发请求的�|�络服务器来��_��U�程池是唯一的解��x��案。线�E�池不光能够避免频繁地创建线�E�和销毁线�E�，而且能够用数目很��的�U�程��可以处理大量客��L��q�发��h��?/div>
   值得注意的是�Q�对于一个压力不大的�|�络服务器程序设计，我们�q�不推荐以上��M��技巧。在��单的设计��p��够完成�Q务的情况下，把事情弄得很复杂是很不明智，很愚蠢的行�ؓ�?/div>
from:
http://blog.chinaunix.net/u2/67780/showart_2057137.html
原文地址 http://blog.chinaunix.net/u/14774/showart_88161.html

chatler 2010-01-04 15:21 发表评论

chatler — Fri, 06 Feb 2009 15:32:00 GMT

介绍

       我们在衡量一个函数运行时��_��或者判断一个算法的旉��效率�Q�或者在�E�序中我们需要一个定时器�Q�定时执行一个特定的操作�Q�比如在多媒体中�Q�比如在游戏中等�Q�都会用到时间函数。还比如我们通过记录函数或者算法开始和截至的时��_��然后利用两者之差得出函数或者算法的�q�行旉��。编译器和操作系�l��ؓ我们提供了很多时间函敎ͼ��q�些旉��函数的精度也是各不相同的�Q�所以，如果我们惛_��到准��的�l�果�Q�必��M��用合适的旉��函数。现在我��׃��l�windows下的几种常用旉��函数�?/div>
1�Q?/strong>Sleep函数

使用�Q?/strong>sleep(1000)�Q�在Windows和Linux�?000代表的含义�ƈ不相同，Windows下的表示1000毫秒�Q�也��是1�U�钟�Q�Linux下表�C?000�U�，Linux下��用毫�U��别的函数可以使用usleep�?/div>
原理�Q?/strong>sleep函数是��调用sleep函数的线�E�休眠，�U�程��d��攑ּ�旉��片。当�l�过指定的时间间隔后�Q�再启动�U�程�Q��l�执行代码。Sleep函数�q�不能�v到定时的作用�Q�主要作用是延时。在一些多�U�程中可能会看到sleep(0);其主要目的是让出旉��片�?/div>
�_�ֺ��Q?/strong>sleep函数的精度非�怽��Q�当�pȝ��忙它精度也��p��低，有时候我们休�?�U�，可能3�U�后才能�l�箋执行。它的精度取决于�U�程自��n优先�U�、其他线�E�的优先�U�，以及�U�程的数量等因素�?/div>
2�Q?/strong>MFC下的timer事�g

       使用�Q?/strong>1.调用函数SetTimer()讄��定时间隔�Q�如SetTimer(0,100,NULL)即�ؓ讄��100毫秒的时间间隔；2.在应用程序中增加定时响应函数OnTimer()�Q��ƈ在该函数中添加响应的处理语句�Q�用来完成时间到时的操作�?/div>
    原理�Q?/strong>�?span>sleep函数一栗��不同的是timer是一个定时器�Q�可以指定回调函敎ͼ�默认为OnTimer()函数�?/span>

    �_�ֺ��Q?/strong>timer事�g的精度范围在毫米�U�别�Q�系�l�越忙其�_�ֺ�也就��差�?/div>
3�Q?/strong>C语言下的Time

       使用�Q?/strong>time_t t;time(&t);Time函数是获取当前时间�?/div>
    原理�Q?/strong>time函数主要用于获取当前旉��Q�比如我们做一个电子时钟程序，��可以��用此函数�Q�获取系�l�当前的旉��?/div>
    �_�ֺ��Q?/strong>�U��?/div>
4�Q?span>COM对象中的COleDateTime�Q?/strong>COleDateTimeSpan�c?/strong>

    使用�Q?/strong>COleDateTime start_time = COleDateTime::GetCurrentTime();

COleDateTimeSpan end_time = COleDateTime::GetCurrentTime()-start_time;
While(end_time.GetTotalSeconds() < 2)
{
// 处理延时或定时期间能处理其他的消�?br>DoSomething()
end_time = COleDateTime::GetCurrentTime-start_time;

}

原理�Q?/strong>以上代表延时2�U�，而这两秒内我们可以��@环调用DoSomething()�Q�从而实现在延时的时候我们也能够处理其他的函敎ͼ�或者消息�?/span>COleDateTime,COleDateTimeSpan�?/span>MFC�?/span>CTime�Q?/span>CTimeSpan�?/span>COM中的应用�Q�所以，上面的方法对�?/span>CTime�Q?/span>CTimeSpa同样有效�?/span>

       �_�ֺ��Q?/strong>�U��?/div>
5�Q?/strong>C语言下的旉��周期clock()

       使用�Q?/strong>   clock_t start = clock();
              Sleep(100);
              clock_t end = clock();
          double d = (double)(start - end) / CLOCKS_PER_SEC;

       原理�Q?/strong>clock()是获取计��机启动后的旉��间隔�?

�_�ֺ��Q?/strong>ms�U�别�Q�对于短旉��内的定时或者�g时可以达到ms�U�别�Q�对于时间比较长的定时或者�g�q�精度还是不够。在windows下CLOCKS_PER_SEC�?span>1000�?/span>

6�Q?/strong>Windows下的GetTickCount()

使用�Q?/strong> DWORD start = GetTickCount();
        Sleep(100);
        DWORD end = GetTickCount();

原理�Q?/strong>GetTickCount()是获取系�l�启动后的时间间隔。通过�q�入函数开始定�Ӟ��到退出函数结束定�Ӟ��从而可以判断出函数的执行时��_��q�种旉��也�ƈ非是函数或者算法的真实执行旉��Q�因为在函数和算法线�E�不可能一直占�?span>CPU�Q?/span>对于所有判断执行时间的函数都是一��P��不过基本上已�l�很准确�Q?span>可以通过查询�q�行定时�?/span>GetTickCount()�?/span>Clock()函数是向��L��BIOS�?/span>real time clock旉��Q�会有中断��生，以及延迟问题�?/span>

�_�ֺ��Q?/strong>WindowsNT 3.5以及以后版本�_�ֺ��?span>10ms�Q�它的时间精度比clock函数的要高，GetTickCount()常用于多媒体中�?/span>

7�Q?/strong>Windows�?span>timeGetTime

使用�Q?/span>需要包�?/span>Mmsystem.h�Q?/span>Windows.h�Q�加入静态库Winmm.lib.

timeBeginPeriod(1);
DWORD start = timeGetTime();
              Sleep(100);
          DWORD end = timeGetTime();
timeEndPeriod(1);

原理�Q?/span>timeGetTime也时常用于多媒体定时器中�Q�可以通过查询�q�行定时。通过查询�q�行定时�Q�本�w�也会媄响定时器的定时精度�?/span>

�_�ֺ��Q?/span>毫秒�Q�与GetTickCount()相当。但是和GetTickCount相比�Q�timeGetTime可以通过timeBeginPeriod�Q?span>timeEndPeriod讄��定时器的最��解析精�? timeBeginPeriod,timeEndPeriod必须成对出现�?/span>

8�Q?span>windows下的timeSetEvent

使用�Q�还记的VC下的Timer吗？Timer是一个定时器�Q�而以上我们提到几�U�时间函数或者类型，实现定时功能只能通过轮训来实玎ͼ�也就是必��d��外创��Z��个线�E�单独处理，�q�样会媄响定时精度，好在windows提供了内�|�的定时器timeSetEvent�Q�函数原型�ؓ

MMRESULT timeSetEvent�Q?UINT uDelay, //以毫�U�指定事件的周期
UINT uResolution, //以毫�U�指定�g时的�_�ֺ��Q�数��D��定时器事�g分��L率越高。缺省��gؓ1ms
LPTIMECALLBACK lpTimeProc, //指向一个回调函�?/span>
WORD dwUser, //存放用户提供的回调数�?/span>
UINT fuEvent �Q?/ 标志参数�Q�TIME_ONESHOT�Q�执行一�ơ；TIME_PERIODIC�Q�周期性执�?/div>
       具体应用�Ӟ��可以通过调用timeSetEvent()函数�Q�将需要周期性执行的��d��定义�?lpFunction回调函数�?如：定时采样、控制等)�Q�从而完成所需处理的事件。需要注意的是：��d��处理的时间不能大于周期间隔时间。另外，在定时器使用完毕后，应及时调用timeKillEvent()��之释放�?/div>
原理�Q?/strong>可以理解��Z��回调函数的timeGetTime

�_�ֺ��Q?/strong>毫秒�Q�timeSetEvent可以通过timeBeginPeriod�Q?span>timeEndPeriod讄��定时器的最��解析精�? timeBeginPeriod,timeEndPeriod必须成对出现�?/span>
9�Q�高�_�ֺ�时控函数QueryPerformanceFrequency�Q?/strong>QueryPerformanceCounter

使用�Q?/strong>LARGE_INTEGER m_nFreq;
          LARGE_INTEGER m_nBeginTime;
          LARGE_INTEGER nEndTime;
          QueryPerformanceFrequency(&m_nFreq); // 获取旉��周期
          QueryPerformanceCounter(&m_nBeginTime); // 获取旉��计数
          Sleep(100);
          QueryPerformanceCounter(&nEndTime);
     cout << (nEndTime.QuadPart-m_nBeginTime.QuadPart)*1000/m_nFreq.QuadPart << endl;

原理�Q?/strong>CPU上也有一个计数器�Q�以机器�?span>clock为单位，可以通过rdtsc��d��Q�而不用中断，因此其精度与�pȝ��旉��相当�?/span>

�_�ֺ��Q?/strong>计算��取硬件支持，�_�ֺ�比较高，可以通过它判断其他时间函数的�_�ֺ�范围�?/div>
10��结�Q?/strong>以上提到常用�?�U�时间函敎ͼ��׃��他们的用处不同，所以他们的�_�ֺ�也不��相同，所以如果简单的延时可以用sleep函数�Q�稍微准��的延时可以使用clock函数�Q�GetTickCount函数�Q�更高��的实�?timeGetTime函数�Q�简单的定时事�g可以用Timer�Q�准��地可以用timeSetEvent�Q�或取一般系�l�时间可以通time�Q�或�?CTime�Q�或者COleDateTime�Q�获取准��的旉��可以用clock�Q�或者GetTickCount函数�Q�或者timeGetTime函数�Q�而获取准��地�pȝ��旉��要��用硬件支持的QueryPerformanceFrequency函数�Q�QueryPerformanceCounter函数�?/div>

chatler 2009-02-06 23:32 发表评论

激情综合中文娱乐网,国产精品制服诱惑,亚洲小视频在线

有关异步��d��、通信

一个基于完成端口的TCP Server Framework,���析IOCP

IOCP

IOCP 与线�E?/a>

An In-Depth Look into the Win32 Portable Executable File Format

一个基于完成端口的TCP Server Framework,��析IOCP