|
What I think GP meant is that [a]synchrony is a property of how one locally handles the need to "wait" for something, and if the protocols being spoken are do not impose order then this is really evident. E.g., A: do thing #0 (no wait)
A: do thing #1 (no wait)
A: do thing #2 (no wait)
B: thing #1 result
A: do thing #3 (no wait)
B: thing #0 result
B: thing #3 result
A: do thing #4 (no wait)
B: thing #2 result
B: thing #4 result
In this example A reads responses from B but never sits idle while "waiting" for those responses.At some point A might need to "block" waiting for all the results for extant requests. What does "block" mean? It could mean: not sending any more requests, not allowing the user to initiate more requests, not being responsive in the UI, and probably more. A could also speak the same protocol synchronously: A: do thing #0
A: <wait>
B: thing #0 result
A: do thing #1
A: <wait>
...
Assuming this protocol does not impose ordering, then, the [a]synchrony property is purely local to A.Even if order is required, A might do other things "while waiting" for responses from B, and that... might be asynchrony. In the traditional Unix single-threaded process model A might block but the system continues to be responsive because the kernel is not synchronous even if A is, and so the kernel can schedule other processes while A "waits" -- but no one would say that A is async in that case, nor would anyone say that the whole system is async either unless A's functionality were spread over multiple processes in such a way that the UI (or whatever) has an "async feel". In reality we might have blocking behaviors even in fully async cases like the first one above owing to flow control, but even there the meaning of "blocking" will depend on what A does when B can't receive more messages due to flow control: A could transmit backpressure to whatever is causing A to generate messages to B, or A could stop generating messages to B, or A could stop being responsive in its UI, or... I believe this is what TFA was getting at: that the meanings of these words (blocking, waiting, asynchronous, etc.) are somewhat fuzzy. Still, when someone says "let's do this asynchronously" I know what they mean, at least for the purposes of the discussion in which it comes up -- in actual design and implementation, once again, the meaning may vary, but the intent is still the same! The intent of doing things asynchronously is to amortize latency and better utilize local resources. |