When Life Gives You No Global Variables, Use Message Passing

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

905

Abstract

separate local RAMs connected by a global bus or network, including, but not limited to, Ethernet or WLAN. The shared memory holds global variables accessible to all involved processes. A modification of a global variable by one process is instantly visible to all other processes. Global variables are evil because they create dependencies that are hard to trace, but they are easy to use. We all know how to read and change their values.When one places processes on different cores with disjoint RAMs, shared memory becomes hard or impossible to implement, even as a virtual abstraction. Message passing comes to the rescue. Processes willing to communicate resort to the operations send() and receive() to request and supply data explicitly. The methods send() and receive() supersede assignment to and readout from a global variable. Both methods can be synchronous (blocking) or asyn

Options

chronous (non-blocking); connection-oriented (through pre-established channels) or connectionless (direct process-to-process); one-to-one, multicast, or broadcast; reliable or unreliable. Message passing is implemented in Smalltalk, Occam, Erlang, Elixir, Golang, and other languages.The core difference between shared memory and message passing is the timing. The shared value in the latter case does not change instantly because of message propagation delay. A programmer must remember that while a message is in transit, the system’s state is undefined. To add insult to injury, message passing wide opens floodgates for deadlocks. An innocent a,b=b,a in Python will cause a deadlock in Erlang or Occam unless implemented with great care.My books on Amazon: <a href="https://www.amazon.com/~/e/B073T6GQJD">https://www.amazon.com/~/e/B073T6GQJD</a></article></body>

A note on distributed programming

Computer science recognizes two principal interprocess communication paradigms: shared memory and message passing.

Shared memory is virtually global RAM accessible to two or more processes. “Virtually global” means it looks like a contiguous address space for all processes, regardless of the physical contiguity and placement. In reality, a virtually global RAM may consist of one block of RAM or separate local RAMs connected by a global bus or network, including, but not limited to, Ethernet or WLAN. The shared memory holds global variables accessible to all involved processes. A modification of a global variable by one process is instantly visible to all other processes. Global variables are evil because they create dependencies that are hard to trace, but they are easy to use. We all know how to read and change their values.

When one places processes on different cores with disjoint RAMs, shared memory becomes hard or impossible to implement, even as a virtual abstraction. Message passing comes to the rescue. Processes willing to communicate resort to the operations send() and receive() to request and supply data explicitly. The methods send() and receive() supersede assignment to and readout from a global variable. Both methods can be synchronous (blocking) or asynchronous (non-blocking); connection-oriented (through pre-established channels) or connectionless (direct process-to-process); one-to-one, multicast, or broadcast; reliable or unreliable. Message passing is implemented in Smalltalk, Occam, Erlang, Elixir, Golang, and other languages.

The core difference between shared memory and message passing is the timing. The shared value in the latter case does not change instantly because of message propagation delay. A programmer must remember that while a message is in transit, the system’s state is undefined. To add insult to injury, message passing wide opens floodgates for deadlocks. An innocent a,b=b,a in Python will cause a deadlock in Erlang or Occam unless implemented with great care.