When are nonblocking read or receive operations useful?

Question

Regardless of library, language, or spec, asynchronous send/write operations make sense to me, because code later in the execution path may not have any dependency upon the success or failure of the write operation.

However, asynchronous receive/read operations are not motivated for me.

Can anyone suggest specific situations or general patterns where async message receipt is useful?

Context

My question is prompted by the MPI specification, but the more general the answer the better. Specifically, there are blocking calls to communicate between processes or machines:

MPI_Send(...) MPI_Recv(...)

and there are analogous nonblocking calls that take an additional parameter MPI_Request * parameter to handle the send/receive operations asynchronously:

MPI_Isend(..., &request) MPI_Irecv(..., &request)

Answer 1

The main reason async read is handy if you still have other work to do or more often because there is another input source you also need to listen to.

For example a GUI you need to listen to the user input besides getting the image from the disk.

Without asynchronous IO you would need to start a new thread every time you start to read something with a blocking API. This won't scale well.

Servers can have several connections active at a time especially when it also communicates with a database and fileserver.

Answer 2

Non-blocking reads can be especially useful in contexts where data may or may not arrive, but if data does arrive it should affect the behavior of an action being performed. For example, if an interactive program that communicates via TCP expects to perform some computations in response to a request, but it's possible that the client might discover--before the computations are complete--that it will no longer be interested in the results, the application might benefit from using a non-blocking read that looks for an "abort" signal. Requiring the client to sent continuous "yes I'm still interested" messages could be annoying, especially if the client has no idea how long the computation will take.

In cases where one wishes to perform several I/O operations independently but they're expected to run to completion, it's often easier and cleaner to use multiple threads than to use asynchronous I/O. In cases where the whole purpose of I/O would be to affect a process which is running on another thread, however, creating an extra thread just to sit on the socket would be wasteful and inelegant.