IO-synchronous, asynchronous, blocking, non-blocking concept

Original: http://blog.csdn.net/historyasamirror/article/details/5778378

When you find that your most popular blog is a big mistake, this is definitely not a pleasant thing to do.
IO-Sync, asynchronous, blocking, non-blocking I wrote when I began to learn Epoll and libevent, and the main idea came from the link in the article. After writing to find a lot of people like, I am still very happy, it also shows that this problem really bothers a lot of people. With the depth of learning, gradually feel the original understanding of some deviations, but still did not arouse their attention, think are some small mistakes, harmless. Until a blogger asked a question, I went back to some more authoritative information, only to find that the original article has a great theoretical error. I do not know how many people have read this blog and have been misled by me, I hereby apologize. I write technology blog will be more rigorous.
Once wanted to delete the original text, and finally did not willing to. After all, each blog has spent a lot of effort, and put it there can also be a warning. So here's a new piece. It's kind of a mend.

Anyway
What is the difference between synchronous (synchronous) IO and asynchronous (asynchronous) Io, blocking (blocking) IO and non-blocking (non-blocking) IO respectively. The problem is that different people may give different answers, such as wikis, that asynchronous IO and non-blocking io are a thing. This is because different people have different knowledge backgrounds, and the context is not the same when discussing this problem. So, to better answer this question, let me first limit the context of this article.
The background discussed in this article is the network IO in the Linux environment.
The most important references in this paper are Richard Stevens's "Unix®network programming Volume 1, third edition:the Sockets networking", and section 6.2 " I/O Models ", Stevens in this section detailing the various IO features and differences, if the English is good enough, recommend direct reading. Stevens's style is famous in simple and simple, so don't worry about not understand. The flowchart in this article is also intercepted from the reference document.

Stevens in the article compares five kinds of Io Model altogether:
Blocking IO
nonblocking IO
IO multiplexing
Signal Driven IO
Asynchronous IO
Since signal driven IO is not commonly used in practice, I'm only referring to the remaining four types of Io Model.

Again, the objects and steps involved in IO.
For a network IO (here we take the read example), it involves two system objects, one that calls this IO process (or thread), and the other is the system kernel (kernel). When a read operation occurs, it goes through two stages:
1 Waiting for data preparation (waiting for the "the" Ready)
2 Copy the data from the kernel into the process (copying the "the" kernel to the)
It's important to remember these two things, because the difference between these IO model is that there are different situations on both stages.

Blocking IO
In Linux, all sockets are blocking by default, and a typical read operation process is probably this:

When the user process invokes the RECVFROM system call, Kernel begins the first phase of IO: Preparing the data. For network IO, most of the time the data did not arrive at the beginning (for example, a full UDP packet has not been received), and kernel will have to wait for enough data to arrive. And on the user process side, the entire process is blocked. When kernel waits for the data to be ready, it copies the data from the kernel to the user's memory, and then kernel returns the result, and the user process unlocks the block state and runs again.
Therefore, blocking Io is characterized by block in both phases of IO execution.

non-blocking IO

Linux, you can make it into non-blocking by setting the socket. When you perform a read operation on a non-blocking socket, the process looks like this:

As can be seen from the diagram, when the user process emits a read operation, if the data in the kernel is not ready, then it does not block the user process, but immediately returns an error. From the user process perspective, it initiates a read operation, does not need to wait, but immediately obtains a result. When the user process determines that the result is an error, it knows that the data is not ready, so it can send the read operation again. Once the data in the kernel is ready and the system call of the user process is received again, it copies the data to the user's memory and then returns.
Therefore, the user process is actually need to constantly actively ask kernel data is good.

IO Multiplexing

The word IO multiplexing may be a little strange, but if I say select,epoll, I'll probably get it. Some places are called this IO mode also for event driven IO. As we all know, the benefit of Select/epoll is that a single process can handle the IO of multiple network connections at the same time. The basic principle of select/epoll is that this function will continually poll all the sockets that are responsible, and notify the user of the process when a socket has data arriving. Its process is shown in figure:

When a user process invokes a select, the entire process is block, while kernel "monitors" all the select-responsible sockets, and the select returns when the data in any one socket is ready. This time the user process then invokes the read operation, copying the data from the kernel to the user process.
The graph and the blocking IO are not much different, in fact, even worse. Because there is a need to use two system call (select and Recvfrom), the blocking IO calls only one system call (Recvfrom). However, the advantage of using select is that it can handle multiple connection at the same time. (Say one more word.) So, if the number of connections is not very high, Web server using Select/epoll is not necessarily better than the Web server using multi-threading + blocking IO, and may be much more delayed. The advantage of Select/epoll is not that it can handle a single connection faster, but that it can handle more connections. ）
In IO multiplexing model, in practice, for each socket, is generally set to become non-blocking, but, as shown above, the entire user's process is in fact always been block. Only the process is being Select this function block, not socket IO to block.

asynchronous I/O

Linux asynchronous Io is actually used very little. Let's take a look at its process:

Once the user process initiates the read operation, you can begin to do something else immediately. On the other hand, from the kernel point of view, when it receives a asynchronous read, first it returns immediately, so no block is generated for the user process. Then, kernel waits for the data to be ready and then copies the data to the user's memory, and when all is done, kernel sends a signal to the user process, telling it that the read operation is complete.

So far, four IO model has been introduced. Now go back to the first few questions: what is the difference between blocking and non-blocking, and what is the difference between synchronous IO and asynchronous IO?
First answer the simplest one: blocking vs non-blocking. In fact, the previous introduction has clearly explained the difference between the two. Calling blocking IO blocks the corresponding process until the operation is complete, and non-blocking IO returns immediately when the kernel is still preparing the data.

Before you explain the difference between synchronous IO and asynchronous IO, you need to give a definition of both. The definition given by Stevens (in fact, the POSIX definition) is this:
A Synchronous I/O operation causes the requesting process to is blocked until that I/O operation completes;
An asynchronous I/O operation does not cause the requesting process to be blocked;
The difference between the two is that synchronous IO will block the process when doing IO operation. According to this definition, the blocking io,non-blocking Io,io multiplexing previously described belong to synchronous IO. One might say that non-blocking io has not been blocked. There is a very "tricky" place where the definition of "IO operation" refers to the real IO operation, which is the example of the Recvfrom system call. Non-blocking IO does not block the process if the kernel data is not ready when executing recvfrom this system call. However, when the data is ready in the kernel, recvfrom will copy the data from the kernel into the user's memory, at which point the process is blocked, during which the process is block. and asynchronous IO is not the same, when the process initiates an IO operation, the direct return is ignored until kernel sends a signal telling the process that IO is complete. Throughout this process, the process has not been blocked at all.

The comparison of each IO model is shown in the following illustration:

The distinction between non-blocking io and asynchronous Io is obvious, as described above. In non-blocking io, although the process will not be block for most of the time, it still requires the process to take active check, and when the data is ready to be completed, it also requires the process to actively call the Recvfrom again to copy the data to the user's memory. and asynchronous Io is completely different. It's like a user process handing over the entire IO operation to someone else (kernel) and then sending a signal when the other person finishes. During this time, the user process does not need to check the status of IO operations, nor does it need to actively copy data.

Finally, give a few examples that are not quite appropriate to illustrate the four IO Model:
There are a,b,c,d four men in the fishing:
A with the most old-fashioned fishing rod, so it has to be kept, wait until the fish hooked on the lever;
B's Fishing rod has a function, can show whether there is fish bait, so, B and next to the MM chat, will see if there is no fish bait, and some words on the quick lever;
C with the fishing rod and b about, but he thought a good way, is to put several fishing rods, and then keep beside, once there is a show said the fish bait, it will be the corresponding fishing rod pull up;
D is a rich man, simply hired a person to help him fishing, once the man catches the fish, he sent a message to D.