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. Pike)

In The Go Memory Model I can read this:

A send on a channel happens before the corresponding receive from that channel completes. (Golang Spec)

There is also a dedicated golang article explaining the quote. And key contribution is a working example also by Andrew G.

Well. Sometimes too much talking around .... I have derived from the Memory Spec quotation and also by looking at the working example this:

After a goroutine1 sends (anything) to a goroutine2 via a channel, then all changes (anywhere in the memory) done by goroutine1 must be visible to goroutine2 after it received via same channel. (Golang Lemma by Me:)

Therfore I derive the Down to earth explanation of the famous quote:

To synchronize memory access between two goroutines, you don't need to send that memory via channel. Good enough is to receive from the channel (even nothing). You will see any changes that were written (anywhere) by the goroutine sending (to the channel) at the time of it's send. (Of course, assuming no other goroutines are writing to the same memory.) Update (2) 8-26-2017

I have actually two questions:

1) Is my conclusion correct?

2) Does my explanation help?

Update (1) I am assuming unbuffered channels. Lets restrict ourselves to that first to avoid overhauling ourselves with too many unknowns.

Please, let's also focus on a simple usecase of two goroutines communicating over a single channel and related memory effects and not on the best practices - that is beyond the scope of this question.

To better understand scope of my question assume that the goroutines may access any kind of memory structure - not only primitve ones - and it can be a large one, it can be a string, map, array, whatever.

Solution 1

In essence, yes. Any values that are assigned to variables before the channel send are eligible to be observed after the channel read, since the channel operation imposes an ordering constraint. But it's important to remember the other part of the equation: if you want to guarantee that those values are observed, you have to make sure that no one else can write to those variables in between the write and the read. Obviously using locks would be possible, but pointless at the same time because if you're already combining locks and cross-thread memory modification, what benefit are you getting from channels? You could pass around something as simple as a boolean, as a token allowing exclusive access to the global data, and it would be 100% correct in terms of the memory model guarantees (as long as your code didn't have bugs), it would just probably be a bad design because you would be making things all implicit and action-at-a-distance-y without a good reason; passing the data explicitly is usually going to be clearer and less error-prone.

Solution 2

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.

Solution 3

I don't think so. The gist is instead of protecting one fixed memory address with a lock or other concurrent primitives, you can architect the program in a way that only one stream of execution is allowed to access this memory by design.

The easy way to achieve this is to share the reference to the memory by channels. Once you send the reference over the channel you forget it. In this way only the routine that will consume that channel will have access to it.

Solution 4

There are two sentences in this; for fuller understanding these must be looked separately first, and then clubbed together, So: Don't communicate by sharing memory; means, different threads should not communicate with each other by complying to the stringent and error-prone memory visibility and synchronization policies like memory barrier etc. (Note that it can be done, but it can soon become complex and very buggy with data races). So avoid complying to manual, programmatic visibility constructs mostly attained thru proper synchronizations in programming languages like Java.

share memory by communicating. means if one thread has made any changes (writes) to a memory area, it should communicate the same (the memory area) to the thread interested in that same memory area; note this has already restricted the scope of memory to only two threads.

Now read the above two paragraphs in conjunction with the golang memory model which says, A send on a channel happens before the corresponding receive from that channel completes. The happens-before relationship confirms that the write by first goroutine will-be visible to the second goroutine receiving the memory reference at the other end of the channel!

Solution 5

Let me go simple and to the point here.

Don't communicate by sharing memory.

It is like when your are communicating using threads for example you have to use variables or mutexes to lock memory for not allowing someone to read and write on it until the communication is complete.

Share memory by communicating

In go routines values move on channels rather than blocking the memory, sender notifies receiver to receive from that channel and hence it share memory by communicating with receiver to get from a channel.

View more solutions

Comments

[honzajde]

Yes, the gist was about something completely else - as you describe in your second paragraph. But if I am wrong where I am wrong then?.

[honzajde]

Thanks for your contributiuon @SirDarius. So far this question I asked is causing me lots of fun:) I hope to everyone else too. But, is your answer to my questions 1) No 2) No ?

[honzajde]

So far this addresses most the point of my question. Thx. Still waiting for Rob P. to say his part though:)

[honzajde]

Thanks for pointing out buffered channels! I have updated my question so that it is obvious that I was assuming unbuffered channels in the first place.

[SirDarius]

I would say, yes, and yes, even though I'm not sure the phrasing of your conclusion sounds "idiomatic" for Go developers, if you see what I mean. The thing that is missing is essentially the notion of passing of ownership.

[honzajde]

This part in your answer is really misleading: "...and give away ownership by sending the value or a pointer to the value to a different goroutine via the channel mechanism" - there is not concept of ownership in go and in fact supposing so leads to race condition if sending goroutine modifies data again.

[SirDarius]

Since there is effectively no notion of ownership, this is down to best practices indeed, which you stated your question is not about. However I'd argue that "share memory by communicating" is a guideline for best practices, specifically, don't reuse variables that you sent through a channel.