Synchronous and asynchronous, blocking, and non-blocking

First of all, I am not very clear about these concepts, the following are some of my directors.

Synchronous and asynchronous, blocking, and non-blocking these are two sets of concepts, saying that different things, synchronous and blocking are not necessarily linked, asynchronous and non-blocking are not necessarily linked. Synchronization and Asynchrony are only related to the state change of the process during IO operations. Blocking and non-blocking are two states of a process. For example, you go to the bank, the elimination of the word is a synchronous way, the word is called the asynchronous way. The queue must see for yourself when it is your turn, and a station call does not have to, it will trigger an event when it is your turn, or you will receive a signal that someone else will say. Whether it is the elimination or the station-to-station, if you can not do other things in the process of waiting, it is blocking mode, otherwise it is non-blocking mode. Synchronization can be blocking and non-blocking, asynchronous time can also have blocking and non-blocking.

Blocking I/O

The I/O operations under Linux are blocked I/O by default, that is, open and socket-created I/O are blocking I/O. When the read-write operation is not completed, the function is not returned and the process is blocked there.

Non-blocking I/O

The use of nonblocking mode is not common, because non-blocking mode wastes a lot of CPU resources.

Listen,recvfrom,connect can cause blocking during network programming. Non-blocking IO is typically used in network programming, the IO request is prefixed with a o_nonblock class of flags, the function returns immediately, the IO is not ready to return an error, and the request process actively polls the IO request continuously until it returns the correct
For example, when calling Recvfrom, if the system has not received the network data, the kernel will return a ewouldblock error immediately.

When an application uses a non-blocking socket, it needs to use a loop to constantly test whether a file descriptor has data readable (called polling (polling)). The application keeps polling the kernel to check if I/O operations are ready. This will be a very wasteful operation of CPU resources. This pattern is not very common in use.

I/O multiplexing

For bulk IP operations, it is very good to use I/O multiplexing.

When I am using I/O multiplexing, we call the Select () function and the poll () function or the Epoll function (the 2.6 kernel begins to support) and block when they are called. When we call the Select function to block, the Select function waits for the datagram socket to enter the read-ready state. When the Select function returns, that is, when the socket can read the data. We can then call the Recvfrom function to copy the data into our program buffer. IO multiplexing is the same as the non-blocking IO nature, but takes advantage of a new select system call, which is the kernel responsible for the polling operation that the request process is supposed to do. It seems that there is more than a non-blocking IO a system call overhead, but because it can support multiple IO, it is more efficient. The advanced point of multiplexing is that it can wait for multiple file descriptors at the same time, and any one of these file descriptors (socket descriptors) goes into a read-ready state, and the Select () function returns. asynchronous I/O when we run in asynchronous I/O mode, if we want to do I/O, we just need to tell the kernel that we are going to do I/O, and then the kernel will return immediately. The specific I/O and copies of the data are all done by the kernel, and our program can continue to execute down. When the kernel completes all I/O operations and copies of the data, the kernel notifies our program.

Synchronous and asynchronous, blocking, and non-blocking