Message Passing

In my opinion, the term “message passing” means “fire and forget”.

A single, atomic operation.

Send ().

Asynchronous.

AFAICT, most current, so-called forms of message-passing consist of two atomic operations:

  1. Send ()
  2. Wait ().

which results in synchronous operation.

Step 2. is usually implied by the use of CALL / RETURN.

A gedanken test of true message-passing would be to convert all instances of all classes into separate threads (ignoring efficiency). One will be forced to convert every “message send” into two atomic operations — Send (), Wait ().

Synchrony is so pervasive that we have sought ways to force-fit synchrony into inherently asynchronous paradigms (e.g. by using envelopes called threads, by implementing synchronous RPC, etc.).

Hardware Support Global Variable

It should be noted that our hardware, since The Stack was invented,1 implicitly supports the synchronous CALL / RETURN paradigm by making The Stack into a global variable that records the dynamic call-chain.

CALL modifies The Stack.

RETURN modifies The Stack.

Threads hide the fact The Stack is a global variable, by wrapping envelopes around it.

See, also, https://guitarvydas.github.io/2020/12/25/The-ALGOL-Bottleneck.html https://guitarvydas.github.io/2021/02/25/The-Stack-is-a-Global-Variable-(again).html

Future

I believe that part of the future of computing lies in removing the redundant Wait ().

We see it beginning to happen with distributed languages like HTML2.

We see it beginning to happen with the exploration of languages based on relations, etc.

We see the need for this arising in technologies like p2p and blockchain (which tend to be concerned with asynchronous operations and network protocols).


  1. Early IBM 360s did not have a Stack. Programmers needed to use the BALR instruction.  ↩︎

  2. See https://guitarvydas.github.io/2020/12/09/CALL–RETURN–Spaghetti.html for an idea on how to implement wait–less Send() on current hardware.  ↩︎