Synchronous/asynchronous and blocking/non-blocking)

Synchronous/asynchronous and blocking/non-blocking)

Asynchronous I/O From Wikipedia, the free encyclopedia

Asynchronous I/O, OrNon-blocking I/O, Is a form of input/output processing that permits other processing to continue before the transmission has finished.

Input and output (I/O) operations on a computer can be extremely slow compared to the processing of data. an I/O device can in‑ate mechanical devices which must physically move, such as a hard drive seeking a track to read or write; extremely slow compared to merely moving electrons. for example, during a disk operation that takes ten milliseconds to perform, a processor that is clocked at one gigahertz cocould have saved ten million instruction-processing cycles.

A simple approach to I/O wocould be to start the access and then wait for it to complete. But such an approach (calledSynchronous I/OOrBlocking I/O) Wocould block the progress of a program while the communications is in progress, leaving system resources idle. when a program makes When I/O operations, this means that the processor can spend almost all of its time idle waiting for I/O operations to complete.

As explained in Wikipedia above, synchronous I/O and blocking I/O mean, asynchronous I/O and non-blocking I/O mean,, there are two or two combinations of the four situations in the actual document. The introduction of an article on the IBM developer network should be correct (or may be more contextual ).

Using asynchronous I/O greatly improves application performance From IBM developerWorks China

Original english text (it is recommended to read the original English text. The translation is not accurate in some places)

AIO Introduction

Linux asynchronous I/O is a new enhancement provided by the Linux kernel. It is a standard feature of the 2.6 kernel, but we can also find it in the patch of the 2.4 kernel. The basic idea behind AIO is to allow a process to initiate many I/O operations without blocking or waiting for any operation to complete. The process can retrieve the results of an I/O operation later or when it receives a notification that the I/O operation is complete.

I/O model

Before going into the aio api, let's first explore the different I/O models that can be used on Linux. This is not a detailed description, but we will try to introduce some of the most common models to explain the differences between them and asynchronous I/O. Figure 1 shows the synchronous and asynchronous models, as well as the blocking and non-blocking Models.

Figure1.BasicLinux I/OSimple Model Matrix

Each I/O model has its own usage mode, which has its own advantages for specific applications. This section briefly introduces them one by one.

Synchronous blocking I/O

I/OIntensive andCPUComparison of intensive processes

I/O-intensive processes perform more I/O operations than I/O operations. CPU-intensive processes perform more processing operations than I/O operations. In Linux 2.6, schedulers prefer I/O-intensive processes because they usually initiate an I/O operation and then block the process, this means that other work can be effectively staggered between the two.

The most common model is the synchronous blocking I/O model. In this model, the user space application executes a system call, which causes application blocking. This means that the application will be blocked until the system call is completed (data transmission is completed or an error occurs ). Calling an application is in a state that does not consume the CPU, but simply waits for a response. Therefore, this is very effective from the processing point of view.

Figure 2 shows the traditional blocking I/O model, which is also the most commonly used model in applications. Its behavior is very easy to understand, and its usage is very effective for typical applications.Before calling Read When the system is called, the application is blocked and context switches are performed on the kernel. Then, the read operation is triggered. When the response is returned (from the device we are reading from), the data is moved to the user space buffer. Then the application unblocks (Read Call back ).

Figure2.Synchronization BlockingI/OTypical Model Process

From the application perspective, the read call will last for a long time. In fact, when the Kernel performs read operations and other work, the application is indeed blocked.

PS. I understand the meaning here that read requests are blocked and there is no asynchronous notification mechanism, because the application has been waiting in this process, that is, it has been actively querying, so it is synchronized. (Sequence)

Synchronous non-blocking I/O

A slightly less efficient variant of synchronous blocking I/O is synchronous non-blocking I/O. In this model, devices are opened in a non-blocking manner. This means that the I/O operation will not be completed immediately, and the read operation may return an error code indicating that this command cannot be met immediately (EAGAIN or EWOULDBLOCK), as shown in 3.

Figure3.Non-blocking SynchronizationI/OTypical Model Process

The non-blocking implementation is that the I/O command may not be immediately satisfied, and the application needs to call it many times to wait for the Operation to complete. This may be inefficient,In many cases, when the kernel executes this command, the application must wait until the data is available or try to execute other work.As shown in positive 3, this method can introduce the latency of I/O operations, because there is a certain interval between the data becomes available in the kernel and the user calls the read returned data, this will reduce the overall data throughput.

PS. I understand what it means here is that the read request is not blocked, but there is no asynchronous notification mechanism here, and the application needs to actively query, so it is synchronized. (Multiple tests)

Asynchronous blocking I/O

Another blocking solution is non-blocking I/O with blocking notifications. In this model,The configured non-blockingI/OAnd then use Blocking Select System Call to determineI/OWhen the descriptor has an operation. What makes the select call very interesting is that it can be used to provide notifications for multiple descriptors, not just for one descriptor. For each prompt, we can request that this descriptor can write data, read data is available, and whether an error occurs.

Figure4.Asynchronous BlockingI/OTypical Model Process(Select)

The main problem with select 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.

PS. I understand the meaning here: the read Request is actually non-blocking, but in the asynchronous notification method, the slect system call is blocked, resulting in the application being blocked, although asynchronous, however, it is blocked. (Wait for the notification and complete it by yourself)

Asynchronous non-blocking I/O (AIO)

Finally, the asynchronous non-blocking I/O model is a model that processes overlapping I/O.Read requests are returned immediately. Read The request has been initiated successfully. When the read operation is completed in the background, the application then performs other processing operations. When Read When the response arrives, a signal is generated or a thread-based callback function is executed to complete this operation.I/OProcessing process.

Figure5.Asynchronous non-blockingI/OTypical Model Process

The overlapping processing capabilities of computing operations and I/O processing to execute multiple I/O requests in a process utilizes the difference between processing speed and I/O speed. When one or more I/O requests are suspended, the CPU can execute other tasks. or, more commonly, when other I/O operations are initiated, the completed I/O operations are performed.

PS. I understand what it means here is that the read Request is actually non-blocking, but the asynchronous notification method uses a callback function, so no application is needed to process it. (Commissioned)

Motivation for asynchronous I/O

From the classification of the previous I/O model, we can see the motivation of AIO. The blocking model requires that the application be blocked at the beginning of an I/O operation, which means that it is impossible to overlap processing and I/O operations at the same time. Synchronous non-blocking model allows overlapping processing and I/O operations, but this requires the application to check the status of I/O operations according to the reproducible rules. In this way, asynchronous non-blocking I/O operations are left, which allow overlapping processing and I/O operations, including notifications of completed I/O operations.

(From: http://eagles1982.spaces.live.com/blog/cns! C2cd7d0a9e34576a! 2626. Entry)