There are 3 definitions of asynchrony that I know of:

  • In event-based programming, asynchrony refers to the execution of tasks in a non-sequential way, which may involve creating another thread. For example with AJAX, we can perform HTTP requests and handle their response in a new thread so that the program doesn't block to wait for results.

  • In communication, a channel is asynchronous if both parties don't need to be present at the same time (e.g., emails), and synchronous if they do (e.g., telephone).

  • In distributed systems, an asynchronous model is one where messages may take an arbitrary long time to transit. It implies that there is no way to know for sure if a node has crashed or it/the network is just being slow.

However I struggle to reconcile these 3 definitions. Is there a common denominator that I'm missing, or is the term asynchrony used in 3 completely different contexts?

Thank you for your help.


1 Answer 1


The unifying definition is that one part of the system triggers an event in another part of the system, and the triggerer does not know when the event will take place.

To put it another way: in a synchronous system, you know when things (will) happen. In an asynchronous system, you don't know when things (will) happen.

In event-based programming, a thread creates another thread, and then it has no control over when the thread will do its job. For example, with AJAX, the new theard performs an HTTP request, and the original thread continues executing without knowing when the HTTP response comes back.

In communication over an asynchronous channel, the sender of a message does not know or care when the recipient will be available receive the message.

In an asynchronous distributed system, the sender of a message does not know when (or possibly even whether) the recipient will receive the message and potentially reply to it.

  • $\begingroup$ Then it seems that the definition of synchrony is a bit different between event-based programming/communication and distributed systems. In the former, the event takes place directly after invocation, while in the latter it may not be the case (even though we have an upper bound on the message delay). I think the cause of my confusion was the different definitions of "synchrony" rather than those of "asynchrony". $\endgroup$ Commented Mar 4, 2021 at 18:09
  • $\begingroup$ @JacopoStanchi No, in event-based programming, the event does not take place directly after the invocation. It takes time for the second thread to reach the point where the event happens, and in the meantime the first thread keeps executing. $\endgroup$ Commented Mar 4, 2021 at 18:19
  • $\begingroup$ Sorry it was a bit misleading. I meant in a synchronous execution, the next instruction is executed directly after the current one, just like in a synchronous channel the channel where the communication takes place directly after the sender has contacted the receiver. I just wanted to point out that the 2 first definitions of synchrony are a bit different than the last one, where a (bounded) delay is tolerated. $\endgroup$ Commented Mar 4, 2021 at 18:26
  • 1
    $\begingroup$ @JacopoStanchi “in a synchronous execution, the next instruction is executed directly after the current one” Not necessarily. That would be real-time synchronous execution. Most systems aren't real-time. There can be an arbitrary time gap between an instruction and the next. And real-time (or close enough) parallel systems are called synchronous, too, even though there can be multiple instructions executing at the same time so there isn't a single “next instruction”: what makes the system synchronous is that you always known when things happen. $\endgroup$ Commented Mar 4, 2021 at 18:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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