A Short Introduction on Asynchronous I/O
Consider the process of how you’d typically place an order at your local In-N-Out restaurant:
You go up to the cashier to place an order of a Double-Double and fries - both Animal Style, of course.
The cashier inputs your order and sends it to the cook, and gives you a receipt with a specific number on it.
You take a seat while you wait for your food.
Cashier takes orders from other customers.
Cook prepares orders as they come and sends them off when they’re complete.
Cashier calls out the number on your receipt.
You pick up your order and enjoy your food.
Asynchronous I/O - also known as non-blocking I/O, is a similar process.
A thread tells the kernel what kind of I/O work it wants complete. (i.e. read from socket/write to file)
Kernel gives the thread a handle to monitor the progress of the work, and adds it to the queue of other I/O requests.
Thread goes on with life, and may periodically check the given handle for any updates.
Kernel sends an update to the handle whenever something pertaining to the request happens.
Thread takes each update, processes it and continues to check for other updates until its request is complete.
Here’s a simple diagram to illustrate what’s going on.
The thread issues its first I/O request (green line) to the kernel; however, since it’s asynchronous, the thread goes on with life while waiting for its response. Down the line, it decides to send another request (purple line). Eventually, the kernel sends updates to the thread once the requests are complete, and the thread picks up on these updates in the order of completion. This is asynchronous I/O - a method of input/output processing which allows processes to continue before the transmission has finished.
Now, let’s look at another approach - synchronous or blocking I/O. If all requests to the kernel were made synchronously, a thread would have to start its request and then wait for it to complete. Such a process would block the progression of a program while the transmission of data is in progress, leaving system resources idle. If many I/O operations were requested, a program can spend a lot of its time sitting idly, waiting for these I/O operations to complete.
So let's go back to our fast food restaurant example and how that would look if it operated like a synchronous operation. You'd still go up to the cashier to put in your order and the cashier would still send it to the cook; but he'd wait until your order is complete. If this restaurant operated sychronously, the cashier would not be able to take orders from the other customers waiting in line behind you, because he'd have to wait until the cook finishes your order to hand off to you.
This is what asynchronous I/O solves. Because it’s possible to send an I/O request, and continue to perform other tasks that do not require the completion of said request, system resources aren’t just sitting around idly because other tasks can be completed at the same time. So if you ever encounter a restaurant that operates in this fashion, you'd better be prepared to wait for quite some time!