On Fri, Nov 27, 2020 at 12:57 PM Daniel Fava <danielsf...@gmail.com> wrote: > > Does anyone know how the Go memory model came to be? I don't have technical > questions about it. I just would like to know the historical context. > > The model is specified in terms of happens-before, due to Lamport. But the > following rule, which allows channels to be used as locks, was not part of > Lamport's original formulation: > > "A receive from an unbuffered channel happens before the send on that channel > completes. " > > I'm curious who (if anyone) was involved in including this rule. How did it > come to be? > > I also find it fascinating how the word "completes" seems to make a world of > difference. As I read it, removing the word "completes" from the rule above > (and from the rule connecting a sender and its corresponding receiver > receiver) would lead to a quite different memory model. I'm curious how > intentional the "completes" is.
As I recall, Tom Szymanski asked for the rules about when one goroutine would see changes made by another goroutine, and how that related to channel operations. Russ Cox described what he thought should happen, Tom encouraged him to write that down, and Russ did, winding up with https://go.googlesource.com/go/+/82c38cf8dd628e6c90b6f1160be2a8d5088b77c9/doc/mem.html (when reading that doc, remember that it was written in February, 2009, and that the syntax has changed since then). The "completes" is intentional. A send/receive on an unbuffered channel was always intended to serve as a synchronization point between the goroutines. Otherwise it would be hard for different goroutines to synchronize on anything. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXQcR7e0QU8rt4NbdLrqGtc92LzYPwWjyAs6u65C8dOUA%40mail.gmail.com.
