This is the 8th day of my participation in the August More Text Challenge. For details, see:August is more challenging
1 BIO(Synchronous blocking I/O)
The user needs to wait for read to read the data in the socket into the buffer before proceeding with the received data. The user thread is blocked during the entire PROCESS of the I/O request. As a result, the user cannot do anything during the I/O request and the CPU resource utilization is insufficient.
Characteristics: The process is blocked during both phases of I/O execution.
advantages
- Data can be returned in a timely manner without delay
- The program is simple, and the process suspends almost no CPU time
disadvantages
- I/O waiting affects performance
- Each connection needs to be handled by a separate process/thread, and memory, thread, and CPU context switches are more expensive to maintain when the number of concurrent requests is high, so they are less commonly used in development environments
2 NIO(Synchronous non-blocking I/O)
The user needs to repeatedly call read to try to read the data in the socket. After the data is read successfully, the user continues to process the received data. In the whole PROCESS of I/O request, although the user thread can return immediately after sending an I/O request each time, it still needs to continuously poll and repeat the request in order to wait for data, which consumes a lot of CPU resources.
Features: Non-blocking I/O mode requires continuous active query of kernel data whether it is ready.
advantages
- When a process is waiting for the current task to complete, it can execute other tasks at the same time. The process will not be blocked in the kernel waiting for data. Each I/O request will be returned immediately, which has good real-time performance
disadvantages
- Continuous polling consumes a large amount of CPU time, reduces system resource utilization, deteriorates performance, and reduces overall data throughput
- This model does not apply to Web servers
3 I/O Multiplexing (Asynchronous Blocking I/O)
The Reactor uses the HANDLE_EVENTS event loop to process the I/O status of the user thread. After registering the handler, the user thread can continue to do other work (asynchronously), while the Reactor thread calls the kernel’s select function to check the socket status. When a socket is activated, the corresponding user thread is notified (or the callback function of the user thread is executed), and the handLE_event is executed for data reading and processing.
Features: There is a mechanism to wait for multiple file descriptors simultaneously, and when any one of these file descriptors (socket descriptors) becomes readable ready, the select()/poll() function returns.
advantages
- Instead of using multiple threads (one thread per descriptor), you can process more connections based on a single blocking object and be readable on multiple descriptors at the same time
- More system resources can be saved
Disadvantages:
- A Web server that uses select/poll may not perform better than a Web server that uses multi-threading + blocking I/O if the number of connections it handles is not large
- The delay may be even larger, because it takes two System calls to process a single number of connections
4 AIO(Asynchronous Non-blocking I/O)
AIO(asynchronous non-blocking IO, or NIO.2). In the asynchronous I/O model, the user thread directly uses the asynchronous I/O API provided by the kernel to initiate a read request, and immediately returns to continue executing the user thread code. At this point, however, the user thread has registered the called AsynchronousOperation and CompletionHandler with the kernel, and the operating system then opens a separate kernel thread to handle the IO operation. When a read request arrives, the kernel is responsible for reading the data from the socket and writing it to a user-specified buffer. Finally, the kernel distributes the read data and the CompletionHandler registered by the user thread to the internal Proactor, and the Proactor informs the user thread of the completion of THE IO (usually by calling the completion event handler registered by the user thread) to complete the asynchronous IO.
Features: Both phase 1 and Phase 2 are kernel completed.
advantages
- Can take full advantage of DMA features to overlap I/O operations with computing, improving performance, resource utilization, and concurrency
disadvantages
- The implementation of the program is more difficult
- To make true asynchronous I/O, the operating system needs to do a lot of work. Currently, Windows implements true asynchronous I/O through IOCP. In Linux system, Linux 2.6 was only introduced, and AIO is not perfect at present. Therefore, the multiplexed I/O model is the main method to realize high concurrency network programming in Linux
5 Signal-driven I/O
Signal-driven I/O means that the kernel uses signals to notify the process that a change has occurred in a file descriptor. In the signal-driven I/O model, a process uses a socket to signal driven I/O and sets up a SIGIO signal handler. When a process makes an I/O call to the kernel through the SIGIO signal handler, the kernel does not prepare a datagram but returns a signal to the process so that the process can proceed to make other I/O calls. In other words, during the first phase of kernel preparation, the process will not be blocked and will continue executing. When the datagram is ready, the kernel delivers a SIGIO signal to notify the user-space signal handler that the data is ready. The process then initiates the recvfrom system call, which is the same as blocking I/O. That is, the process is also blocked during the second phase of the kernel copying data into user space.
The entire process of signal-driven I/O is shown below:
Stage 1 (non-blocking) :
- The kernel returns a signal to the process when the datagram is not ready. At this time, the process can continue to do other things
- ② : After the kernel loads the data in the disk to the kernel buffer, it will submit the SIGIO signal to the user space signal handler
Stage 2 (blocking) :
- ③ : After the process received SIGIO signal program, the process to the kernel system call (recvFROM)
- (4) : The kernel then copies the data in the kernel buffer to the process buffer in user space (the phase of the real IO process), until the data replication is complete
- ⑤ : the kernel returns the instruction of successful data processing to the process; The process processes the data packet after receiving the instruction; After the processing is complete, the process is removed from the uninterruptible sleep state and the next I/O operation is performed
Features: With the help of socket signal driving I/O and SIGIO signal processing function
advantages
- Threads are not blocked during the first phase (data wait), improving resource utilization;
disadvantages
- The implementation of the program is more difficult
- Signal I/O may not be notified when a large number of IO operations are performed due to signal queue overflow. Signal-driven I/O, though, is useful for handling UDP sockets, where the signal-driven I/O indicates that a datagram has arrived or that an asynchronous error has been returned. For TCP, however, signal-driven I/O is nearly useless, because there are so many conditions that lead to such notification, each of which consumes a lot of resources and loses the advantage over the previous approaches
Signal notification mechanism
- Horizontal trigger: indicates that the recvfrom system call was not initiated by the process because it was busy after the kernel notified the process that the kernel buffer was ready. The kernel sends the notification again, and the loop repeats until the process requests the recvFROM system call. Obviously, this approach frequently consumes too many system resources
- Edge trigger: The kernel sends a notification only once