Analysis of IO Model-blocking, non-blocking, IO multiplexing, signal driven, asynchronous IO, synchronous IO

Recently saw OvS user-state code, in receiving the kernel state information, the use of Epoll multiplexing mechanism, it is very puzzled, so from the Internet to find some information, learning a bit of "UNIX Network into Volume 1: Socket Network API" this book corresponding chapters, online although there are many blog posts about the topic, And the explanation is very detailed, but here still do a study note, record your thoughts.

IO model

In the book UNIX Network becomes Volume 1: Socket Networking API, five I/O models are mentioned, namely: blocking I/O, non-blocking I/O, I/O multiplexing (epoll, select are an I/O multiplexing mechanism), information-driven I/O, asynchronous I/O, Here is a detailed introduction.

Blocking I/O model

Blocking, as the name implies, when the process is waiting for data, if the data has not been generated, then the process will wait until the waiting data is generated, the process state is blocked.

As shown in Linux, the user-state process calls the RECVFROM system call to receive data, the current kernel is not ready for data, the user-state process will be waiting here, no other operations, waiting for the kernel to prepare the data, the data from the kernel state copy to the user space memory, The recvfrom then returns a successful indication, at which time the user state is unblocked and the received data is processed.

As can be seen from the above process, the user state receives the kernel state data, there are two main processes: the kernel state to obtain data, and the data from the kernel state memory space copied into the buffer of the user state process

Non-blocking I/O model

In a non-blocking I/O model, when the process waits for the kernel's data, and when that data does not arrive, the process keeps asking the kernel until the kernel has the data ready.

For example, the user-state process call Recvfrom receive data, there is no data message generated, at this time recvfrom return Ewouldblock, the user state process will always call recvfrom ask the kernel, when the kernel ready data, then the user state process no longer ask the kernel, When the data is copied from the kernel to the user space, Recvfrom successfully returns and the user state process begins processing the data.

It is important to note that when data is copied from the kernel to the user space, the user-state process is in a blocked state.

Non-blocking I/O model, personally think that the name may be a little confusing, not with the blocking model is completely opposite, not to say that the process is not the data, to do other things, just process this time has been waiting for the arrival of data, and the blocking model is different, non-blocking equivalent to the process has been knocking at the door asked " The data is ready, give me ", and then the person behind the door said," Not ready, please later! ", this process is a polling state, and the blocking style is the attitude of the Buddha, knocked a door, the door after the people did not give any response, so go to sleep, do nothing, until the door after the person to make a response to wake him up, the process to do the next move.

I/O multiplexing model

In the OvS user-state source code, the use of the I/O multiplexing model, in the computer network, there is a lot of "multiplexing" usage, such as multiplexing, meaning that a link can only be transmitted one data stream at a time, if you want to achieve the two sources of data flow between multiple streams, it will need more links, However, multiplexing technology can transmit multiple data streams at the same time by dividing a link into frequencies or dividing the transmission times.

Apply to the I/O multiplexing model, can correspond to the following scenario: If a process needs to wait for a number of different messages, then the general practice is to open multiple threads, each thread receives a class of messages, if each thread is a blocking I/O model, then each thread is not generated when the message is blocked, This means that blocking I/O is used in multiple threads. I/O multiplexing is based on the above scenario, without the use of multi-threaded listening messages, the process directly listens to all the message types, which involves the Select, poll, Epoll and other different methods.

As shown, the user-state process takes the Select method, the select can wait for several different types of messages, and if one of the types of messages is ready, then select returns the information and then the user-state process calls Recvfrom to receive the data.

The select reuse mechanism can be thought of as a collection of descriptors that can be managed by placing different descriptors in the collection, waiting for different messages to be generated, and then managing them uniformly by select, allowing them to wait for the generation of any event in the collection at the same time.

I/O multiplexing and blocking I/O are similar, except that I/O multiplexing waits for multiple classes of events, blocking I/O waits for only one class of events, and in I/O multiplexing, there are two system calls (for example, select and Recvfrom), while blocking I/O results in only a single system call. So this involves a specific performance problem, when there is only one type of event, the performance of using the blocking I/O model is better, when there are many different types of events, the performance of I/O multiplexing is much better, because the blocking I/O model can only listen to a class of events, so this time need to use multi-threaded processing.

Signal-driven I/O model

In the signal-driven I/O model, there is an essential difference between blocking and non-blocking, which is that the user-state process no longer waits for kernel-state data to be ready to do anything else directly.

As shown, when the need to wait for data, the first user state will send a signal to the kernel, tell the kernel what data I want, and then the user state is no matter, do something else, and when the kernel in the data is ready, the kernel immediately sent to the user state a signal, said "data is ready, come and check", After receiving the user-state process, call Recvfrom immediately, wait for the data to be copied from the kernel space to the user space, and after completion recvfrom return to the success instructions, the user state process to deal with other things.

The above diagram shows that the signal-driven I/O model has the bright of an asynchronous operation, but the user-state process is blocked during the time the data is copied from the kernel to the user space

asynchronous I/O model

The asynchronous I/O model is more complete than the signal-driven I/O model.

For example, the first user-state process tells the kernel what data needs (in the Aio_read), and then the user-state process is no matter, do other things, the kernel waits for the user state needs to prepare the data, and then copy the data to the user space, at this time to tell the user state process, "data are ready, please check", The user-state process then processes the data for the user space directly.

The user-state process is also non-blocking during this time period of replicating data to user space

Synchronous I/O

"UNIX Network becomes Volume 1: Socket Networking API" This book does not describe synchronous I/O as a separate I/O model, and before I read it, I have always thought that the blocking I/O is equivalent to synchronous I/O and non-blocking I/O is equivalent to asynchronous I/O. Can not be seen simply through the literal meaning of judgment.

By describing these I/O models, I can conclude that the blocking I/O, nonblocking I/O, and I/O multiplexing models are synchronous I/O models, because in the process of waiting for the data, the processes in these three models do not do anything else, even if the non-blocking polling can be considered as a synchronization.

The book also argues that the signal-driven I/O model is synchronous I/O, which says that POSIX defines the synchronous IO operation as "causing the request process to block until I/O operation is complete," and the book considers that the time to wait for data in the signal-driven I/O model is not really I/O operation (because I is not called /o related system calls), and the data is copied from the kernel to the user space is the real I/O operation (this time called the Recvfrom system call).

I/O model comparisons

The picture in the book is very clear, from the time period of waiting for data and data copying, pointing out the differences between the different I/O models, which are not mentioned here.

Summarize

Read a lot of information from the Internet, different bloggers on the five model summary of the situation is different, no exception, the basic use of a life scene to describe their differences, but I personally feel that some of the scene description is too simple, not the difference between different models described completely, here I also give a life scene as a summary, Of course this is just my own idea, the wrong comment area can be pointed out.

We go to the restaurant to eat, will pass the following steps: First, according to the menu order, then wait for the kitchen ready, then the waiter serving. In this scenario, waiting for the kitchen to prepare the dishes is equivalent to waiting for the data, waiter serving the same as the data from the kernel to the user space, you are the user-state process, the waiter and the restaurant as a kernel-state process.

Blocking I/O model: Just order a dish, then start waiting at the table, do nothing in the process, and wait for the waiter to put the dish on the table before it starts to eat.

Non-blocking I/O model: Just order one dish, then start waiting, do nothing, wait a moment and ask the waiter, "is my dish ready?" "Not good to wait, after a while and then ran to ask ...." Repeat the process until the waiter says "Pro, your dish is ready, I'll give it to you now", and then you sit on the table waiting for the waiter to deliver the meal to your table before you start eating.

I/O multiplexing model: You ordered a lot of dishes, and then began to wait, some time one of the dishes or a number of dishes in the kitchen at the same time, the waiter ran over and said, "Pro, you have some of the dishes are good, to the table now?" "You answer, now on, so the waiter a dish (waiter only one dish at a time), you eat one, the last you eat a ...

Signal-driven I/O model: Just order a dish, then leave the phone to the waiter, tell him that the dish is ready to make a call to you, do not serve, then you go out to play, wait until the food is good, the waiter mobile phone notify you, you immediately returned to the restaurant, said to the waiter, "You can now serve", So you wait at the table for the waiter to bring the dish up and eat.

asynchronous I/O model: Just order a dish, then leave the phone to the waiter, tell him the dishes are ready to serve, the dishes on the table to call you, and then you go out to play, wait until the table, waiter mobile phone notify you, you immediately returned to the table, began to eat.

Resources

UNIX network becomes Volume 1: Socket Networking API
Blocking, non-blocking, synchronous, asynchronous summarization of network IO
IO-synchronous, asynchronous, blocking, non-blocking (post-mend)

Segmentfault to should post page 1190000016359495