Networked systems - what's the difference between a "blocking" and a "non-blocking" protocol?

Question

In computer networking - and in a lot of other fields actually - I hear a lot of reference to the terms "blocking", "non-blocking", "synchronous", and "asynchronous". I was wondering if anyone could explain in pretty straightforward/simple terms what these are supposed to mean?

Answer 1

A "blocking" call "blocks" the program that calls it until it completes. Your program has to wait for it to do (whatever) before the next statement runs. Most function calls are "blocking," for example, set x to 4 + 4 will not go on to the next statement until it computes the value of 8 and assigns it to x. Likewise, a blocking or synchronous network method will hold up the calling program until it completes. In the case of something like "send a packet to a remote system," this time may be measurable in seconds, or longer, instead of the microseconds (or less) that arithmetic consumes.

A "non-blocking" or asynchronous method usually, instead, either deposits its results in a "mailbox" or "queue" of some kind, or (more commonly) will call back a function that you provide when it completes. This is often/usually better for a program that does anything else (for example, displaying a user interface) while it's waiting on a relatively slow network process to complete.

When accessing relatively fast local services, like local disc I/O, inter-process communications on one computer, or sending output to a local display, blocking I/O is sometimes preferred because it's easier to write.

Example of blocking network I/O:

set web-page to (the result of) get url "http://www.google.com/"
in web-page, find <title>...</title>,
     assign this to google-title;
if not found,
     present a warning, and
     set google-title to "Google"
do something else…

versus:

get url "http://www.google.com/" and call back google-title-callback
do something else…

function google-title-callback, accepts web-page:
    in web-page, find <title>...</title>,
         assign this to google-title;
    if not found,
         present a warning, and
         set google-title to "Google"

Asynchronous I/O is almost always used at the application level for GUI programming, as well. For example, a terminal (stream)-based program might be synchronous awaiting for user input, while a GUI program might be asynchronous, allowing you to randomly choose various controls or perform other actions (like resizing a window) that require it to accept messages of various times through either callback methods or event handlers, which more-or-less amount to the same type of thing as the network callback example, above.

Answer 2

What is the underlying issue?

IO subsystems generally have orders of magnitude greater latencies than simple instruction processing (in CPU). This latency is also non-deterministic (while of course within known bounds).

IO subsystems are also typically (all?) independent from the system processor. While this is positive in the sense that it allows concurrent actions in distinct (hw) components of the system, it also highlights the fact that the system in total also needs to couple the distinct IO and CPU components by providing data and control info transfer.

As a generalization then, we are talking about cooperating interconnected (active) components. Typically this is a master/slave relationship, but that is not the general case, e.g. this applies to peer-to-peer connectivity, as well.

+-----+                 +-----------+
| dev | <==== DATA ====>| processor |
|     | <---- ctrl -----| <master>  |
+-----+                 +-----------+

(Note that 'device' can be memory, network, disk, or another process. Further note there are 3 sub-systems here, the 'bus' or 'connection' between the two peers is also a system with latencies, bandwidth, capacity, etc.)

The terms synchronous, asynchronous, blocking, and non-blocking, address and define the semantics of communication/interconnection between the two linked components.

• Blocking & Non-Blocking

These terms address call semantics.

In a blocking call, the component that initiates an exchange suspends all activity until the transfer of control and/or data to the other component is completed.

In an non-blocking call, the component that initiates an exchange basically performs a fire and (possibly) forget.

• Synchronous & Asynchronous

These terms address patterns of interaction (protocol).

In a synchronous interaction, the two component will act in lock-step and the interaction is fully deterministic. Fundamentally, we can say that there is a known, deterministic, and finite set of actions that will take place in a synchronous exchange between the components.

In an asynchronous interaction, the two components are not coordinating in lock-step (thus termed asynchronous). Fundamentally, we can say that there is an unknown set of actions that can occur in either component in course of completing an exchange.

It would likely clarify to append a "response" to these terms, e.g "Synchronous-Response", as this both fully spells out the general idea, and, disambiguates the synchrony from blocking (which is a common conceptual error).

• Note

Per above, obviously we have a system design space that is the permutation of {block, non-block} X {synch, asynch}. E.g. a system may use non-blocking call semantics with an asynchronous protocol.

Discussion

In general, it is fair to say that we, human programmers, prefer sequential and fully deterministic models: they are simpler to conceive, develop or grok, frankly.

But, being system geeks, we also like efficiency and performance, right?

Per our diagram above, we note 3 distinct (and both independent) sub-systems. Wouldn't it be nice if 'processor' above could tell the 'bus' to 'send xyz to dev' and not wait until the bus says 'ok, I did that'? That would be a non-blocking call. (Note it does not in any way address synch or async protocol!)

Also, what if the overall system would benefit if 'processor' got to do some other work while waiting for the response to complete an exchange? That would be an asynchronous exchange.