Io and file read/write-differences between synchronous/asynchronous and blocking/non-blocking

First, we will explain the concepts of synchronous and asynchronous, which are related to the notification mechanism of messages.

For example, if I go to a bank to handle business operations, I may choose to wait in queue or take a small note with my number, the person at the counter informed me that it was my turn to handle the business when I arrived.

The former (waiting in queue) means waiting for messages synchronously, while the latter (waiting for notifications from others) means waiting for messages asynchronously. in asynchronous message processing, a callback mechanism is often registered for the waiting message (in this example, the waiting person is the person waiting for the Service to be processed, when a waiting event is triggered, the trigger party (the person at the counter here) finds the person waiting for the event through a mechanism (the number written on the small note here.

In actual programs, synchronous Message Processing is like a simple read/write operation. They need to wait until these two operations are successful before returning; the asynchronous processing mechanism is similar to select/poll and other multiplexing Io operations. When the concerned message is triggered, the message trigger mechanism will trigger the processing of the message.

Next, let's explain the blocking and non-blocking concepts. These two concepts are related to the status when the program waits for messages (synchronous or asynchronous.

In the above example, whether waiting in queue or waiting for notifications by number, if the waiting person cannot do anything other than waiting for messages during the waiting process, the mechanism is blocked, it is manifested in the program, that is, the program has been blocked and cannot continue to be executed in the function call. on the contrary, some people like to call and send text messages while waiting for these services in the bank. This status is non-blocking, because they (waiting) the Message notification is not blocked, but waits while doing your own thing.

However, you must note that the first non-blocking synchronous mode is actually inefficient. Imagine that you still need to look up while you are on the phone to see if the team has exceeded you, if you think of the call and the position of the observation queue as two operations of the program, the program needs to switch back and forth between the two different actions, the efficiency can be imagined is low; while the latter, asynchronous non-blocking mode does not have such a problem, because the call is your (waiting for) thing, and the notification is the counter (message trigger mechanism) thing, the program does not switch back and forth in two different operations.

Many people will confuse synchronization and blocking. I think it is because many times the synchronization operation will be displayed as blocking. For example, many people will write blocked read/write operations, but don't forget to set the o_nonblock flag for FD so that the synchronization operation can be turned into non-blocking. Similarly, many people will confuse asynchronous and non-blocking operations, this is because asynchronous operations are generally not blocked in real Io operations. For example, if the select function is used, the read operation will not be blocked when the select function returns readable, it is like when your number is arranged, it is generally because you have no one before, so you will not be blocked when you go to the counter to handle the business.

It can be seen that synchronous/asynchronous and blocking/non-blocking are two different concepts, they can coexist and combine, or you can refer to here:
Http://www.ibm.com/developerworks/cn/linux/l-async/

Synchronous and asynchronous: As mentioned above, synchronous and asynchronous are only about how messages are notified, rather than message processing. In other words, in synchronous mode, the message handler waits for the message to be triggered, while in asynchronous mode, the trigger mechanism notifies the message handler.

Therefore, in the asynchronous mechanism, a connection bridge is required between the message handler and the trigger mechanism. In our example, the bridge is the number on the small note, in select/poll and other IO multiplexing mechanisms, FD is used. When a message is triggered, the trigger mechanism finds the processing function for processing the FD through FD.

Please understand the concepts of Message notification and message processing. This is the key to understanding this problem. back to the example above, it is your turn to handle the business. This is the message you are concerned about, and to handle the business is to process the message, there is a difference between the two. in actual Io operations, the message concerned is whether the FD can be read and written, and the message processing is to read and write the FD. synchronous/asynchronous systems only focus on how to notify messages. They do not care about how to process messages. For example, the bank only notifies you that it is your turn to handle the business, they do not know how to handle the business.

Many people confuse synchronization and blocking because they do not distinguish these two concepts, such as blocking read/write operations, in fact, the Message notification and processing message are combined. The message concerned here is whether the FD is readable/written, while the message processing is the FD read/write. when we set this FD to non-blocking, the read/write operation will not block the Message notification. If FD cannot be read or written, the Operation will return immediately.

Many may ask again, isn't asynchronous operations blocked? If a message has been notified that it can be processed, it must not be blocked, right?
In fact, asynchronous operations can be blocked, but they are not blocked when processing messages, but blocked when waiting for a message to be triggered.For example, in the select function, if the input last timeout parameter is null, the program will always block this select call if no event is triggered. if asynchronous non-blocking is used, such as AIO _ * Group operations, when I initiate an aio_read operation, the function will immediately return and will not be blocked, when the event of interest is triggered, the previously registered callback function will be called for processing. For details, see the article in my connection above. back in the above example, if the bank waits for the person to handle the business to wait for the message to be triggered asynchronously, that is, a small piece of paper is received, if he cannot leave the bank to do other things during this time, it is clear that this person is blocked in this waiting operation;, the man suddenly found himself addicted to smoking and needed to go out to smoke, so he told the lobby manager that, when the number is exceeded to me, please contact me outside (register a callback function), so he will not be blocked in this waiting operation, naturally, this is the asynchronous + non-blocking method.