Roughly analogous to mail processes (both surface and electronic), non-blocking style communications allow both sender and receiver to perform their activities independent of the state the other may be in at the time.

• Features:

  Here, too, there are definite gains and some possible drawbacks to this style of communication:

  • Allows maximum opportunity for overlapping computation and communication

    The most significant advantage of asynchronous communication is that it provides the application the opportunity to constructively use the time that would otherwise have been spent idly waiting; the performance gains from this are potentially very significant, as the operations entailed in communications are characteristically much slower than those encountered in normal computation, hence the savings are disproportionately greater for every cycle you manage to overlap the two.

  • Requires separate status checking, and buffer management

    You are expected to do a bit more work, however: you won't be automatically notified when the transmission is completed, you have to remember to ask ... and you can't reuse the buffer you've set aside for the operation until the operation is completed.

• send: immediate return after posting function, user buffer cannot be safely modified until runtime library indicates that the operation is complete

  One of the most time-consuming parts of communications operations is that of buffer copying, from user-space to system-space or vice versa, or from working storage to transmission storage, etc. Asynchronous, non-blocking sends, if coded properly, relieve part of that burden at the expense of another: your communication process won't be slowed down by buffer-copying, but, in order to provide that, you won't be able to re-use that buffer until the communication has finished. Being asynchronous, the sender simply issues the call, then goes on with other tasks.

• receive: immediate return after posting function, user buffer cannot be safely used until runtime library indicates that the operation is complete

  Exactly the same applies to the receive-side: space is allocated for the message, and a separate instruction stream (a process or thread, depending on the implementation ... the latter is preferable in terms of overhead) is spawned off to deal with the actual operation, while the main stream continues on with other things.