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?


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)

  • 2
    when you are receiving on multiple points Mar 9, 2015 at 15:49
  • @ratchetfreak, hmm.. That seems straightforward enough. If that gets fleshed out a bit as an answer, I'll accept.
    – kdbanman
    Mar 10, 2015 at 0:33
  • Are you asking about MPI specifically or just blocking vs non-blocking I/O in general? Mar 10, 2015 at 3:27
  • Async I/O in general.
    – kdbanman
    Mar 10, 2015 at 16:45

2 Answers 2


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.

  • In socket programming, using async reads and writes is very common as it lets you handle multiple sockets simultaneously in a single thread. This lets you avoid all of the fun synchronization issues you get with lots of threads. Mar 10, 2015 at 22:04

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.