Analysis of UNIX IO model

The provisions in POSIX for synchronous IO and asynchronous IO :

Synchronous IO Operation: Causes blocking of process until IO operation completes, asynchronous IO operation: IO operation does not cause process blocking

under UNIX, there are 5 operating models :

Blocking IO, non-blocking io,io multiplexing, signal-driven IO, asynchronous IO

According to the network, the first four types are synchronous Io, the fifth type is asynchronous IO, for this conclusion, my understanding is based on whether the user process is blocked to judge (not the kernel process). For some discussion of synchronous and asynchronous, refer to http://bbs.chinaunix.net/viewthread.php?tid=947563

Blocking IO

This is the IO model we are familiar with, when a process is doing IO operations, it is not returned until the data is copied from the kernel space to the user process space. The advantage of this model is that it is simple, and when blocking, the CPU can also be dispatched to perform other processes.

non-blocking IO

At first I looked at the non-blocking IO, I think it should be more advanced than the blocking IO model, but when I look at the use of the method, I know that this model is not actually used, only as the theoretical existence of the IO model. The view of this model is that the IO operation is not blocked, and if no data is prepared, the error code (or other code) is returned directly. Therefore, the user can only keep polling to invoke the IO function. The consequence of this is that not only is there a total "blocking" effect on the macro and blocking Io, but on the microscopic level, the CPU has been used for polling, resulting in a waste of CPU. Therefore, this model is not as useful as blocking IO models.

io multiplexing

For IO multiplexing, I understand that there are three points:

In a system call, IO readiness to interrogate multiple descriptors is implemented-based on event notification in order to achieve the 1th, it is necessary to transfer the blocking place. Make a system call, divided into two system calls. The first system call can ask for the IO readiness of multiple descriptors, and the second system call is called for the descriptor that is ready for IO, which, in theory (as I understand), is blocked, but the kernel has already prepared the data. The time to block is negligible. In essence, it is still blocked.

Signal IO

As we all know, the signal is that UNIX provides a way for communication between processes. Our usual kill-9 command (kill is to pass the semaphore to the process, 9 is one of the many signals), or Ctrl + C, is to signal a process to terminate, so the process exits.

And for the signal IO model, I understand that: the process after initiating the IO operation, after the system call, direct access, the kernel will be ready after the IO data, a signal to the initiation of the IO operation process, so that the process's signal processing function can read the operation of IO data.

In essence, this is also the blocking IO model, because in the signal processing function, the same is to be blocked, but at this time to launch the system system, the kernel has already prepared the data.

Asynchronous IO

This is the real asynchronous IO. The implementation of the mechanism is: when the user initiates the asynchronous IO system call, the corresponding data processing function as a callback function, wait until the IO data is ready, the kernel will actively call this callback function. As you can see, in this model, the user process invokes only one system call and returns immediately, so there is no case of blocking the process, and it conforms to the definition of asynchronous IO in POSIX.

In fact, I understand that the idea is similar to the signal IO, the only different place, for the operation of IO data, asynchronous IO is initiated by the kernel, and the signal IO is initiated by the user process.

Analysis of UNIX IO model