Explain: Don't communicate by sharing memory; share memory by communicating

Question

I wonder what is the most down to earth explanation of this famous quote:

Don\'t communicate by sharing memory; share memory by communicating. (R. Pik

Answer 1

This famous quote can be a little bit confusing if taken too litterally. Let's break it down to its more basic components, and define them properly:

Don't communicate by sharing memory; share memory by communicating
      ---- 1 ----    ------ 2 -----  ---- 3 -----    ----- 4 -----

1. This means that different threads of execution would be informed of the change of state of other threads by reading memory that would be modified somewhere else. A perfect example of this (although for processes instead of threads) is the POSIX shared memory API: http://man7.org/linux/man-pages/man7/shm_overview.7.html. This technique needs proper synchronization because data races can occur pretty easily.
2. Here this means that there is indeed a portion of memory, physical or virtual, that can be modified from several threads, and read from those, too. There is no explicit notion of ownership, the memory space is equally accessible from all threads.
3. This is entirely different. In Go, sharing memory just like above is possible, and data races can occur pretty easily, so what this actually means is, modifying a variable in a goroutine, be it a simple value like an int or a complicated data structure like a map, and give away ownership by sending the value or a pointer to the value to a different goroutine via the channel mechanism. So ideally, there is no shared space, each goroutine only sees the portion of memory it owns.
4. Communication here simply means that a channel, which is only a queue, allows one goroutine to read from it and so be notified of the ownership of a new portion of memory, while another one sends it and accepts to lose ownership. It is a simple message passing pattern.

In conclusion, what the quote means can be summed up like this:

Don't overengineer inter-thread communication by using shared memory and complicated, error-prone synchronisation primitives, but instead use message-passing between goroutines (green threads) so variables and data can be used in sequence between those.

The use of the word sequence here is noteworthy, because it describes the philosophy that inspired the concept of goroutines and channels: Communicating Sequential Processes.