Summary of 5 types of IO models under Linux

Overview

In contact with network programming, we often deal with various IO-related concepts: synchronous (synchronous), asynchronous (asynchronous), blocking (blocking), and non-blocking (non-blocking). On the difference of concept see a friend (link) in the know-how to play a comparative image of the metaphor:

You call the bookstore boss there is no "distributed System" this book, if it is a synchronous communication mechanism, the bookstore owner will say, you wait, "I check", and then start to check Ah, and so check (maybe 5 seconds, may be a day) to tell you the results (return results).
and the asynchronous communication mechanism, the bookstore owner directly told you I check Ah, check the phone to you, and then directly hung up (do not return the results). And then check it out and he'll call you on his own initiative. Here the boss calls back by "callback" this way.

You call to ask the bookstore owner whether there is a "distributed System" book, if you are blocking calls, you will always "hang" until the book has no results. If the call is non-blocking, you don't care if the boss tells you that you're going to play on your own, and of course you have to check in a few minutes occasionally to see if the boss has returned the results.

Here the blocking is independent of the non-blocking and whether synchronous asynchronous. It has nothing to do with how the boss responds to your results.

The main difference between synchronous and asynchronous is that it will not cause the request process (or thread) to block . Synchronization causes the request process (or thread) to block and not asynchronously.

There are five common IO models under Linux, of which there is only one asynchronous model and the rest are synchronous models.

Blocking IO Model

The blocking IO model is the most common IO model, and the default mode for all "slow devices" (sockets, Pipes, FIFO, terminal) IO is blocked. Blocking is the process that discards the CPU and gives it to other processes to use the CPU. The most noticeable manifestation of process blocking is "process sleep." The time to block usually depends on whether the data arrives.

Non-blocking IO model

Non-blocking IO is the setting of IO-related system calls to non-blocaking, and subsequent IO operations are returned immediately with or without available data, and set errno to Ewouldblock or Eagain. We can make sure that the IO is in effect with the active check (polling, polling) and the associated IO operation. Of course, this approach seems to be less reliable, wasting too much CPU time, polling with precious CPU time is too some numbers. Icon:

Multiplexed IO Model

Multiplexing is the system call that allows blocking to occur on our multiplexed IO operation, rather than the one we really go to execute io. The advantage of using this approach is that you can monitor multiple file descriptors for IO at the same time. Detailed use of the way before wrote a blog has mentioned: http://www.cnblogs.com/ittinybird/p/4574397.html

Signal Driven IO Model

The so-called signal-driven, is to use the signal mechanism, the installation of Signal Sigio processing function (for IO-related operations), through the monitoring file descriptor, when it is ready, notify the target process for IO operation (signal handler). How to use this blog also has a description: http://www.cnblogs.com/ittinybird/p/4574397.html

Asynchronous IO Model

The asynchronous IO on Linux has a set of POSIX-defined interfaces that have several syscall at the beginning of the AIO. As follows:

int aio_read (struct AIOCB *aiocbp); int aio_write (struct aiocb *aiocbp);

ssize_t Aio_return (struct AIOCB *aiocbp);

                                  Remember Link WITH-LRT when you use it.

The parameters seem to give a very concise illusion. In fact, compared to other models of the parameters of one is not less, just put in the structure of the body inside. First look at the structure of the struct AIOCB the prototype bar, the header file is "Aio.h".

 structaiocb{intAio_fildes;/*File Desriptor. */   intAio_lio_opcode;/*operation to be performed. */   intAio_reqprio;/*Request priority offset. */   volatile void*aio_buf;/*Location of buffer. */size_t aio_nbytes; /*Length of transfer. */   structSigevent aio_sigevent;/*Signal number and value. */   /*Internal. */   structAIOCB *__next_prio; int__abs_prio; int__policy; int__error_code; __ssize_t __return_value;       #ifndef __use_file_offset64 __off_t Aio_offset; /*File offset. */   Char__pad[sizeof(__off64_t)-sizeof(__off_t)];#else__off64_t Aio_offset; /*File offset. */#endif   Char__unused[ +];};

In fact, although the structure is long enough, in fact, the actual use of the previous parameters, it is not so complicated. The specific usage will not be mentioned. Specifically, you can refer to the blog: http://blog.csdn.net/tq02h2a/article/details/3825114.

is a diagram of the asynchronous IO Model:

Reference

AIO (7)-Linux manual page http://man7.org/linux/man-pages/man7/aio.7.html

Sigevent (7)-Linux manual page http://man7.org/linux/man-pages/man7/sigevent.7.html

5 Photos of the Model "UNIX Network Programming Volume 1" Stevens

Summary of 5 types of IO models under Linux