Summary of Linux under Synchronous mode, asynchronous mode, blocking call, non-blocking invocation

Synchronous and asynchronous: related to the notification mechanism of a message .

	Essential differences	Practical examples
Sync mode	To wait for the message to be triggered by the person handling the message	I go to the bank to handle business, choose to queue, etc., row to the end of the deal.
Asynchronous mode	By triggering mechanism to notify the person who processed the message	I went to the bank to transact business, take a small note with my number, and wait until the line to my this number by the counter to inform me that my turn to transact business.

Blocking and non-blocking: related to the state of a thread waiting for a message ( regardless of synchronous or asynchronous ) .

	Essential differences	Practical examples
Blocking calls	The thread hangs and cannot do anything else.	The above example, whether queued or using a number to wait for notification, if in the process of waiting, waiting for the wait, in addition to waiting for the message can not do other things, then the mechanism is blocked.
Non-blocking calls	Threads are active and can handle other things.	When the bank handles these business, while calling and sending text messages while waiting, this state is non-blocking.

Examples of combinations between them:

	Blocking calls	Non-blocking calls
Sync mode	Read/write	Read/write O_nonblock
Asynchronous mode	IO multiplexing: Select/poll,epoll (LT mode)	AIO series: Aio_read,aio_write etc; Epoll (et mode)

Synchronous Blocking IO

One of the most common models is the synchronous blocking I/O model. In this model, the user-space application executes a system call, which causes the application to block. This means that the application will block until the system call is complete (data transfer is complete or an error occurs). The calling application is in a state where the CPU is no longer consumed and simply waits for a response, so it is very effective from a processing point of view.

Figure 1 shows the traditional blocking I/O model, which is one of the most commonly used models in the current application. Its behavior is very easy to understand, and its usage is very effective for typical applications. When the read system call is invoked, the application blocks and the kernel is context-switched. The read operation is then triggered, and when the response returns (from the device we are reading from), the data is moved to the buffer of the user space. The application will then unblock ( read call back).

Figure 1. Typical flow of a synchronous blocking I/O model

From the application's perspective, the read call lasts for a long time. In fact, when the kernel performs read operations and other work, the application is indeed blocked.

Synchronous non-blocking I/O

A slightly less efficient variant of synchronous blocking I/O is synchronous non-blocking I/O. In this model, the device is opened in a non-blocking form. This means that the I/O operation does not complete immediately, and the read operation may return an error code stating that the command is not immediately satisfied (Eagain or Ewouldblock), as shown in 2.

Figure 2. Typical process for synchronizing non-blocking I/O models

The non-blocking implementation is that the I/O command may not be immediately satisfied, requiring the application to call many times to wait for the operation to complete (polling). This can be inefficient, because in many cases, when the kernel executes this command, the application must be busy waiting until the data is available, or trying to perform other work. As shown in 2, this method can introduce the latency of the I/O operation because there is a certain interval between the data being available in the kernel to the return data of the user call read , which results in a decrease in overall data throughput.

Asynchronous blocking IO

Another blocking solution is non-blocking I/O with blocking notifications. In this model, a non-blocking I/O is configured, and then select a blocking system call is used to determine when an I/O descriptor is operational. The select interesting thing about making a call is that it can be used to provide notifications for multiple descriptors, not just one descriptor. For each prompt, we can request that the descriptor can write data, have read data available, and notify if there is an error.

Figure 3 Typical flow of an asynchronous blocking IO model (SELECT)

selectThe main problem with calling is that it is not very efficient. Although this is a convenient model for asynchronous notifications, it is not recommended for high-performance I/O operations.

Asynchronous non-blocking IO

Finally, the asynchronous nonblocking I/O model is a model that handles I/O overlap. The read request returns immediately, stating that read the request has been successfully initiated. When the read operation is completed in the background, the application then performs other processing operations. When read the response arrives, a signal is generated or a thread-based callback function is executed to complete the I/O process.

Figure 4 Typical flow of an asynchronous nonblocking IO model

The ability to overlap compute operations and I/O processing in a process to perform multiple I/O requests takes advantage of the difference between processing speed and I/O speed. When one or more I/O requests are suspended, the CPU can perform other tasks, or, more commonly, the I/O already completed while initiating additional I/O.

motivation of Asynchronous IO

From the classification of the front I/O model, we can see the motive of AIO. This blocking model requires blocking the application at the start of the I/O operation. This means that processing and I/O operations cannot overlap at the same time. The synchronous nonblocking model allows processing and I/O operations to overlap, but this requires the application to check the status of I/O operations against the recurring rules. This leaves asynchronous nonblocking I/O, which allows processing and I/O operations to overlap, including notification of completion of I/O operations.

In addition to blocking, select functions provide functionality (asynchronous blocking I/O) similar to AIO. However, it is blocking the notification event rather than blocking the I/O call.

Summary of Linux under Synchronous mode, asynchronous mode, blocking call, non-blocking invocation