The difference between Linux synchronous/asynchronous and blocking/non-blocking

The concept to be explained today is: the difference between synchronous/asynchronous and blocking/non-blocking. These two sets of concepts are often confusing because they all involve IO processing. At the same time, there are some similar places. First of all, to explain the concept of synchronization and asynchronous, these two concepts are related to the notification mechanism of the message. For example, if I go to the bank to handle business, I may choose to wait in line or take one. I have my number on the small note. When I get to this number, the person at the counter informs me that it is my turn to go through the business. The former (waiting in line) is synchronous waiting for the message, while the latter (waiting for notification) is asynchronous. Waiting for messages. In asynchronous message processing, the waiter (in this case, the person waiting for the business) often registers a callback mechanism that is triggered by the trigger mechanism (here the counter person) when the waiting event is triggered. Some kind of mechanism (in this case, the number written on the small note) finds the person waiting for the event. In the actual program, synchronous message processing is like a simple read/write operation, they need to wait for these two The operation is successful, and the asynchronous processing mechanism is a multiplexed IO operation similar to select/poll. When the message of interest is triggered, the message trigger mechanism notifies the triggering of the message processing. Secondly, it explains the blocking. And non-blocking, these two concepts are related to the state when the program waits for a message (no matter whether it is synchronous or asynchronous). Continue the above example, whether it is queuing or using the number to wait for notification, if in this waiting process, the waiter waits in addition to waiting No other things can be done outside the message, then the mechanism is blocked, which is manifested in the program, that is, the program is blocked at the function call and cannot continue to execute. On the contrary, some people like to handle these services in the bank. When I call and send a text message while waiting, this state is non-blocking, because he (waiter) does not block in this message notification, but waits while doing his own thing. But need to pay attention, first The synchronous non-blocking form is actually inefficient. Imagine you still need to look up and see the bottom team as you call. You haven't. If you think of the location of the call and the observation queue as two operations of the program, the program needs to switch back and forth between these two different behaviors, and the efficiency can be imagined to be low; The asynchronous non-blocking form has no such problem, because the call is your (waiter) thing, and the notification is the counter (message trigger mechanism), the program does not switch back and forth between two different operations. People will confuse synchronization and blocking, I think because many times synchronization will be expressed in the form of blocking, such as many people will write blocking read /write operations, but don't forget to set the O_NONBLOCK flag on fd, so Synchronous operations can be made non-blocking; similarly, many people will also confuse asynchronous and non-blocking, because asynchronous operations are generally not blocked at the real IO operation, such as if you use the select function, when select returns When you read it, you will not be blocked. It is like when your number is listed, it is usually no one before you, so you will not be blocked when you go to the counter. Visible, the same /Asynchronous and blocking/non-blocking are two different concepts, they can coexist and combine, you can also see here: http://www.ibm.com/developerworks/cn/linux/l-async/finished this last night After the article, I came to see the feedback this morning, and I read it a few times at the same time. I found that there are still some places where the explanation is not clear enough. I will continue to supplement and refine my statement here. I hope I will not be more confused. Synchronous and asynchronous: As mentioned above, synchronous and asynchronous are just mechanisms for how the message of interest is notified, not the mechanism for processing the message. That is to say, in the case of synchronization, it is processed by the message owner to wait for the message to be triggered, and In the case of asynchronous, the trigger mechanism is used to notify the message handler. Therefore, in the asynchronous mechanism, a bridge of connection is needed between the message sender and the trigger mechanism. In our example, the bridge is the number above the small note. In the IO multiplexing mechanism such as select/poll, it is fd. When the message is triggered, the trigger mechanism finds the processing function for processing the fd through fd. Please pay attention to understanding the two concepts of message notification and processing messages. The key to solving this problem is to go back to the above example. It is your turn to handle the business. This is the message you care about, and going to the business is the processing of this message. There is a difference between the two. In the real IO operation. The message of interest is whether the fd is readable and writable, and the processing of the message is to read and write the fd. Synchronous/asynchronous only pays attention to how to notify the message, they do not care about how to process the message, for example, The bank's people only inform you that it is your turn to handle the business, and they don't know how to handle the business. Many people confuse synchronization and blocking, I think because there is no distinction between these two concepts, such as blocking read/In the write operation, the message notification and the processing message are actually combined. The message of interest here is whether fd is readable/writable, and the processing message is read/write to fd. When we set this fd to non- When blocking, the read/write operation will not block waiting for the message notification. If fd is not readable/writable, the operation will return immediately. Many people will ask, the asynchronous operation will not be blocked. It has been notified that there is a cancellation. Can be processed, it must not be blocked? In fact, asynchronous operations can be blocked, but usually not blocked when processing messages, but blocked when waiting for messages to be triggered. For example, select function, if passed in The last timeout parameter is NULL, then if none of the events of interest are triggered, the program will block at the select call. If asynchronous non-blocking is used, such as the aio_* group operation, when I initiate an aio_read In operation, the function will return immediately and will not be blocked. When the event of interest is triggered, the previously registered callback function will be called for processing. For details, please refer to the article given in the above connection. Back to the above example, If the person waiting for the business at the bank is using an asynchronous way to wait for the message to be triggered, that is, to get a small note, if during this time he can't leave the bank to do other things, then obviously this The man was blocked in the waiting operation; but, this person suddenly found himself smoking a cigarette and needed to go out to smoke, so he told the lobby It is reasonable to say that when I am in trouble with this number, I will notify me outside (register a callback function), then he will not be blocked on this waiting operation. Naturally, this is asynchronous + non-blocking.