4

I'm giving a presentation about the Go Memory Model. The memory model says that without a happens-before relationship between a write in one goroutine, and a read in another goroutine, there is no guarantee that the reader will observe the change.

To have a bigger impact on the audience, instead of just telling them that bad things can happen if you don't synchronize, I'd like to show them.

When I run the below code on my machine (2017 MacBook Pro with 3.5GHz dual-core Intel Core i7), it exits successfully.

Is there anything I can do to demonstrate the memory visibility issues?

For example are there any specific changes to the following values I could make to demonstrate the issue:

  • use different compiler settings
  • use an older version of Go
  • run on a different operating system
  • run on different hardware (such as ARM or a machine with multiple NUMA nodes).

For example in Java the flags -server and -client affect the optimizations the JVM takes and lead to visibility issues occurring.

I'm aware that the answer may be no, and that the spec may have been written to give future maintainers more flexibility with optimization. I'm aware I can make the code never exit by setting GOMAXPROCS=1 but that doesn't demonstrate visibility issues.

package main
var a string
var done bool

func setup() {
    a = "hello, world"
    done = true
}

func main() {
    go setup()
    for !done {
    }
    print(a)
}
stephenbez
  • 5,598
  • 3
  • 26
  • 31
  • 4
    How about using the [race detector](https://blog.golang.org/race-detector)? It reports an error on the above program. – Charlie Tumahai Jan 20 '19 at 23:49
  • Code doesn't finish on playground https://play.golang.org/ – Uvelichitel Jan 20 '19 at 23:55
  • 2
    @Uvelichitel That's because the Playground has `GOMAXPROCS=1`, so the for loop will never yield and the other goroutine won't run. This is a problem but is separate from memory visibility problems. If I set `GOMAXPROCS=2` it will return: https://play.golang.org/p/0uImutl7UPT – stephenbez Jan 21 '19 at 00:09
  • @ThunderCat yeah I'll be demonstrating the race detector. Some people seem to think that memory visibility issues are just a theoretical but not practical concern, and if I can demonstrate it actually happening it would be more convincing than saying it could happen. See part on "my programs have ben working for years", here: https://stackoverflow.com/questions/2787094/how-to-demonstrate-java-multithreading-visibility-problems – stephenbez Jan 21 '19 at 00:16
  • 7
    One of the impediments to reliably reproducing observable reorderings is that Intel processors generally implement a stronger memory model than is required by the language. (This is certainly true in Java.) Which means if your systems are Linux, Windows, or Mac, you are probably already starting with one hand tied behind your back. But your question belies a wrong way of thinking. Yes, users want to be shown "what breaks." But such failures are generally rare probablistic events, not deterministic failures. And said users are thinking deterministically. Teach them to think otherwise. – Brian Goetz Jan 21 '19 at 01:20
  • @BrianGoetz Yeah I knew Intel processors would make it more difficult. If only I could run my code on DEC Alpha. You are right that I should focus on teaching people to think about things probabilistically instead of deterministically. Otherwise they might think it works on my machine so it must be right. I just wanted to say I love your "Java Concurrency in Practice" book and it has been a great help! – stephenbez Jan 21 '19 at 01:45
  • 2
    "Is there anything I can do to demonstrate the memory visibility issues?" Not much. But ask yourself: If someone is interested in the memory model of a language then he/she is probably senior enough to know that race conditions are a 100% no go even if given a certain CPU and a certain workload the race might not manifest. – Volker Jan 21 '19 at 05:52
  • Recently I tried to illustrate memory issues through: diagrams, small tests to illustrate incorrect programs, race detector and `go vet` (mutex usage) detection - https://medium.com/dm03514-tech-blog/golang-candidates-and-contexts-a-heuristic-approach-to-race-condition-detection-e2b230e70d08 – dm03514 Jan 21 '19 at 13:20

0 Answers0