Asynchronous programming in. NET (4)-I/O completion port and FileStream. BeginRead

The original idea of writing this series is to discuss the changes in asynchronous programming style in. NET, especially the asynchronous workflow in F # And the task-based asynchronous programming model in. NET 5.0 in the future. However, after three articles, many people are very interested in the implementation principle behind IO Asynchronization and why high performance can be improved. In fact, I don't want to spend more text on the implementation details of these underlying layers. I am not good at these aspects, and I will use them. NET asynchronous IO does not need to care about these underlying things, because it has been fully encapsulated for you. However, in order to avoid repeated discussions, I still inserted an article in this series to explain it.

In this article, I will start from the kernel object I/O completed port, and then let's take a look at how FileStream. BeginRead in. net bcl uses I/O to complete port implementation.

IO Completion Port)

Most people should have heard more or less about the I/O port and know that it is a powerful tool for high-performance I/O and high-scalability applications. The I/O completion port is a very complex Kernel Object, and its implementation is also very clever. It is very interesting to think carefully.

A basic principle for creating highly scalable applications is to create fewer threads. Fewer threads consume less resources first. In addition to wasting CPU time, the creation of each thread also creates a series of data structures to save thread-related information: User stacks, thread context, Kernel stack, etc. This total is about mb. How much memory can you calculate for your 32-bit machine? How many threads can be created? Some people may say that it doesn't matter if it is 64-bit. Well, there is no need to worry about the 64-bit resource occupation. However, the more threads you can run in the system, the limited number of CPUs (8? 80 ?). In Windows, the task scheduling mechanism is that each thread runs a time slice, and then another thread runs in Windows preemptive scheduling. The more threads, the more frequent thread context switching is required for Windows. The impact of thread context switching on system performance is not mentioned here. You can search for information.

So how can we create fewer threads and do more? The answer is "Don't wait ". For the CPU, the speed of the I/O device is almost low. Just like the difference between an airplane and a tractor, we can't let the tractor drag the plane back. The IO completion port is generated for this purpose: create fewer threads and do more things.

The I/O completion port is not a visible plug-in, but also different from the port 80. You can think of it as a data structure or an object (below I will use the C # code to explain IO port completion, just to explain, these codes are not actually implemented ):

Windows provides a CreateIoCompletionPort API to create an I/O completion port. In fact, this API has two functions: Creating an I/O completion port and binding an I/O device to this port. There is an important parameter when creating an I/O completion port: specify the maximum number of threads that can be run in parallel at the same time. This is to ensure fewer threads. If you set this value to 0, the default value is the number of CPUs on your machine. There is also an IO Device handle list in the IO port. You can bind many device handles to this port (file, Socket, etc ):

// Function prototype

HANDLE CreateIoCompletionPort(

    // Device handle

    HANDLE     hFile, 

    // The existing IO completed port handle. If this parameter is already specified, the previously specified device is bound to this port.

    HANDLE     hExistingCompletionPort,

    // Many devices can be bound to an I/O port.

    ULONG_PTR  CompletionKey, 

    // Number of threads allowed to run simultaneously

    DWORD      dwNumberOfConcurrentThreads