undefined | Better HN

0 pointspcwalton13y ago0 comments

I've heard conflicting things here. I was under the impression that Go was not memory safe while mutating maps without synchronization.

For example, these articles allude to possible memory corruption:

http://golang.org/doc/articles/race_detector.html "memory corruption"

http://golang.org/doc/faq#atomic_maps

http://talks.golang.org/2012/splash.article "Go is not purely memory safe in the presence of concurrency."

0 comments

1 comments · 1 top-level

4ad13y ago

You are correct, I was presenting a simplified view.

While Go was designed with memory safety in mind, the specification does not guarantee memory safety. With that being said, it also doesn't preclude it (unlike C). For example, the gc implementation without parallelism (not to be confused with concurrency) is memory safe while the gc implementation with parallelism is not. This is the reason why GOMAXPROCS is always 1 in the playground and on the App Engine. There's nothing precluding a paralel implementation from also being memory safe.

j / k navigate · click thread line to collapse