Five I/O models in Unix, unix

Five I/O models in Unix, unix

There are five I/O models in Unix:
1. Blocking I/O
2. Non-blocking I/O
3. I/O multiplexing (select and poll)
4. Signal-driven I/O (SIGIO)
5. asynchronous I/O (POSIX aio _ series functions)

Io requests are divided into two steps:
　1. copy the data from the storage medium (disk, network, etc.) to the kernel buffer. This is called data preparation and can be read by your application.
2. the user application copies the data in the kernel buffer to the user buffer. 

① The process of blocking the I/O model is blocked until the data copy is completed.

We regard the function recvfrom as a system call. No matter how the function is implemented, there is usually a switch from running in the application process to running in the kernel, after a period of time, a switch will be returned to the application process.

An application calls an I/O function, causing application congestion and waiting for data to be ready. If the data is not ready, keep waiting. If the data is ready, the data is copied from the kernel to the user space, and the IO function returns a successful indication.

A process calls recvfrom. This system call will not be returned until the datagram arrives and is copied to the buffer zone of the application process or when an error occurs. Common Errors include system calls being interrupted by signals.

The process is blocked from the start of calling recvfrom to the whole time it returns. After the function returns successfully, the application process starts to process the datagram.

② Non-blocking I/O model data is always polling before it is ready

When we set a set of interfaces to non-blocking, we will tell the kernel that when the requested I/O operation cannot be completed, do not sleep the process, but return an error. In this way, our I/O operation functions will continuously test whether the data is ready. If not, continue the test until the data is ready. In this continuous testing process, it will take a lot of CPU time.

No data is returned when recvfrom is called three times before, so the kernel returns an EWOULDBLOCK error immediately. When recvfrom is called for the fourth time, the datagram is ready and copied to the application buffer zone. If recvfrom returns a successful response, the next step is to process the data.

When an application process calls recvfrom cyclically for a non-blocking descriptive word like this, we call this process polling ). Since the application process continuously queries the kernel like this to see if a certain operation is ready, this is a great waste of CPU time, so this model is only occasionally encountered.

③ I/O Reuse Model adds a system call select to help the process monitor multiple I/O

The I/O reuse model uses select or poll functions. These two functions can also block the process, but they are different from those that block I/O, these two functions can block Multiple I/O operations at the same time. In addition, I/O functions of multiple read operations and write operations can be detected at the same time. I/O operation functions can be called only when data is readable or writable.

As long as data is ready, the select call returns, and the application calls recvfrom to copy data from the kernel to the user zone.

Looking at the instance diagram, we found that the select model seems to be somewhat disadvantage, that is, two system calls were performed before and after, one more time than the previous model. However, the select model also has its obvious advantages: After a select statement is blocked and returned, multiple ready sockets can be obtained (that is, one select statement can manage multiple sockets, similar to monitoring whether multiple socket events are ready at the same time ).

Compared with the blocking IO model, the selectI/O Reuse Model is equivalent to blocking in advance. When the data arrives, calling recv will not block the data.

④ The signal-driven I/O model process confirms that the data is ready through the received signal

We can use signals to notify us of the signal SIGIO when the kernel is ready. This method is called Signal-driven I/O.

First, we allow the socket to perform signal-driven I/O and install a signal processing program by calling sigaction. This system call returns immediately, and the process continues to work. It is non-blocking. When the datagram is ready to be read, a SIGIO signal is generated for the process. We can then call recvfrom in the signal processing program to obtain the read datagram.

⑤ The asynchronous I/O process is not blocked and the task is handed over to the kernel for processing

Let's start the kernel and notify us after the entire operation is completed (including copying data from the kernel to our own buffer.

Call the aio_read function to tell the kernel description, buffer pointer, buffer size, file offset, and notification method, and then return immediately. When the kernel copies the data to the buffer, it notifies the application.

Comparison of five I/O models

The main differences between the first four models are in the first stage, because the second stage of the first four models is basically the same: when the data is copied from the memory to the caller's buffer zone, the process blocks the recvfrom call. However, the two phases of asynchronous I/O model processing are different from those of the first four models.

Synchronous I/O and asynchronous I/O

• Synchronous I/O: The request process is blocked before the I/O operation is complete.
• Asynchronous I/O: Before I/O operations are completed, the request process is not blocked.

The first four of the above five I/O models are synchronous I/O (they have different wait methods and the same relocation action), because the recvfrom call blocks the current request process.

Only the last type of io is asynchronous I/O!

 

After data is synchronized from the storage medium to the kernel buffer (the data preparation process), you need to copy the data to the user buffer.
The so-called asynchronous method does not care about Step 1 or 2. You only need to initiate an IO request and then obtain the IO result.
Therefore, the first four IO models are synchronized !!!

 

Blocking, non-blocking, synchronous, and asynchronous generalization:

• Blocking, non-blocking:Whether the data to be accessed by the process/thread is ready, and whether the process/thread needs to wait;

• Synchronous and asynchronous:The data access method requires active Data Reading and Writing during synchronization. Blocking occurs during Data Reading and Writing. asynchronous data only requires notifications completed by I/O operations and does not actively read and write data, the operating system kernel reads and writes data.