For IOCP, there is no stranger to programming on Windows servers. Its performance is beyond the expectations of other WinSock models. The purpose of this article is to enable you to thoroughly understand IOCP and explore the performance of Windows. Here, we assume that you have a deep understanding of the IOCP model and a certain understanding of Windows threads and thread pools. If you are not familiar with this yet, read this article after learning and understanding the content.
In IOCP model programming, we often need to consider how many threads are created to complete the execution thread. In many cases, this is a decision-making problem that requires a lot of skills and experience. In most cases, we adopt a policy to check the number of CPUs on the server and assume that each CPU executes two threads at most. Then, the number of threads we create is the number of CPUs * 2. This seems reasonable, but in fact, in the complex server application environment, the results are not satisfactory. In many cases, we hope to get a more dynamic and flexible solution.
Some experienced programmers write their own thread pool libraries to achieve this dynamic and flexible management method, which can also achieve certain scalability. For example, the system dynamically adds some CPU resources, or when the system is heavily burdened, or when the CPU is low due to frequent thread switching, the thread pool is dynamic.
Simply put, on platforms over Windows2000, we have already provided thread pool interfaces. Although these interfaces sometimes seem a little simple, such as the famous QueueUserWorkItem function, these interfaces are too simple to know how many active threads are in the current thread pool. You can only use other tools to dynamically observe and guess. However, this simplicity also brings us convenience and benefits for calling. Of course, when it comes to Windows and later platforms, the thread pool functions have been greatly enhanced, and you can control more things, for details about the thread pool of Windows2008, refer to another blog titled "Windows2008 thread pool foresight".
In terms of combining IOCP and thread pool, the Windows system also comes up with this difficulty for programmers. The Windows system simply binds IOCP and thread pool inside the system, provides a thread pool function with IOCP-BindIoCompletionCallback.
The original form of this function is as follows:
Bool winapi BindIoCompletionCallback (
_ In HANDLE FileHandle,
_ In LPOVERLAPPED_COMPLETION_ROUTINE Function,
ULONG Flags
);
You need to define the prototype of the required completion process (actually the IOCP thread process) Function as follows:
Void callback FileIOCompletionRoutine (
[In] DWORD dwErrorCode,
[In] DWORD dwNumberOfBytesTransfered,
[In] LPOVERLAPPED lpOverlapped
);
People familiar with IOCP may be excited about vascular inflation, right?
From the parameters of the BindIoCompletionCallback function, you should have been able to guess the usage of this function. The first handle is the file handle or SOCKET handle you need to bind, handle of other I/O devices. The pointer to the second function is the pointer to your completion routine. This function is fully implemented and controlled by you. The last Flags parameter must be assigned a value of 0 to all current Windows systems, this parameter is not used yet.
So simple? Incredible. Where is the handle of IOCP? In fact, you do not need to consider which IOCP handle and how many threads are created, the only thing you need to worry about is how to write the completion routine and how to bind an I/O handle with the completion routine. In the past, it took n lines of code to complete the task. A BindIoCompletionCallback function was done completely, and we didn't even need to consider the thread dynamics. All of this is now a comprehensive consideration of the Windows system, and you are freed.
Why? Go to your high availability, high scalability, and high dynamic IOCP large service application!
Author: zhongguoren666