io-synchronous, asynchronous, blocking, non-blocking, reading summary

Http://www.cnblogs.com/Fly-Wind/p/io.html

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

As described above, the difference between non-blocking io and asynchronous io is obvious. In non-blocking io, although the process will not be blocked for most of the time, it still requires the process to go to the active check, and when the data is ready, it is also necessary for the process to proactively call Recvfrom to copy the data to the user's memory. and asynchronous Io is completely different. It's like a user process handing over an entire IO operation to someone else (kernel) and then sending a signal notification when someone finishes it. During this time, the user process does not need to check the status of the IO operation, nor does it need to actively copy the data.

Finally, the two concepts of block and synchronous asynchronous clear, after reading a personal summary: To determine whether the block is based on whether the user process block is waiting for the data phase, the judgment is synchronous or asynchronous basis is to copy the data from the kernel state to the user state is the kernel active or user process initiative.

First to the landlord point a praise, hard. Synchronous asynchronous understanding is still relatively easy, and the use of JavaScript inside the Ajax is a reason, but for blocking and non-blocking understanding a little bit difficult, I read a few times with their own understanding that the so-called blocking and non-blocking is a definition of the operating system, if it is blocked Io, Then the operating system will block the process or thread of the IO operation, take its CPU execution, and the non-blocking IO because of the feedback in the process of reading, so I need to use a polling to determine whether the real read, so the operating system will not take its CPU execution. From another point of view, blocking IO can cause frequent context switching, while non-blocking IO takes too long CPU time and is a waste of CPU.

To landlord: Select/epoll is not good and multithreading simple comparative advantage. There are many reasons for this. Multithreaded coding is complex, and debug is relatively difficult. The performance of Linux history on-line is not too good (relative to other OS threads). In order to reduce the complexity of multi-threaded coding maintenance, Linux is encouraged to use the multiplexing IO. You can look at the performance of x server (using IO multiplexing).

Reply Hit_fantasy: Personal understanding, hope to help you (of course, may be wrong): asynchronous has a very obvious feature is that the kernel sends a read "message" to the user layer (the user process has only one boot IO system call, and then goes to other things, the kernel completes the copy through the message to the process said " It's done. "). Instead of an asynchronous operation, the program itself calls the system to tell the kernel what to do next (1.select gets a readable fd,2,read copy data from the kernel layer to the user layer)

io-synchronous, asynchronous, blocking, non-blocking, reading summary