5 ms·
Worth to note that they address this concern in a way in the doc: > Correctness. There is one non-performance concern. Increased parallelism could make bugs in
by akavel 11y ago
Worth to note that they address this concern in a way in the doc:
> Correctness. There is one non-performance concern. Increased parallelism could make bugs in racy programs more likely to cause crashes or other problems. The setting of GOMAXPROCS=1 may have thus far let those bugs go undetected. Raising it may therefore make buggy programs less reliable. We hope that both the race detector and the introduction of goroutine preemption and interleaving in Go 1.1 has already helped programmers identify and eliminate many such bugs. In any event, we can’t reasonably hobble the performance of working Go programs for fear of breaking buggy ones. If such buggy programs do turn up, the authors can set GOMAXPROCS=1 explicitly to keep them working until the bugs can be fixed.
- twoodfin 11y agoAs someone with little experience in Go, I'm curious: How do racy programs end up crashing? Do they just end up in some inconsistent state and panic or can you actually trigger a CPU fault?
- kasey_junk 11y agoSetting something to nil and then referencing it is a trivial race condition to create which can cause a crash.
- twoodfin 11y agoThanks for this response, and all the others. For some reason I had it in my head that Go's CSP concurrency model precluded sharing of that kind.
- tptacek 11y agoGolang's CSP idiom precludes that sharing. The language itself was explicitly designed not to preclude it: if you know what you're doing (or, unfortunately, don't), you can easily design concurrent data structures using locks or atomic operations. Golang doesn't even cordon this stuff off as "unsafe"; like in most languages, shared mutable is the default. That said: unlike, say, string counting idioms in C, the share-using-channel idiom in Golang is powerful, in the sense of: it's what most people reach for by default. For a language as opinionated as Golang, it's extraordinarily pragmatic. It is designed first and foremost to be a tool, and then a lot of other things, before being a statement about how to design safe programs.
- pcwalton 11y agoI don't actually know of a single language that has locks and atomics, but marks them unsafe. All languages I know of either have them and mark them safe and idiomatic (for example, Golang or Rust), or don't have them at all (for example, Erlang).
- dvirsky 11y agoYou get weird little unexplained panics, more or less. Stuff like nil pointer references, errors with map/slice access, and deadlocks.
- pcwalton 11y agoYou can segfault with arbitrary undefined behavior [1], but I've never heard of it happening in practice. [1]: http://research.swtch.com/gorace http://research.swtch.com/gorace
- firethief 11y agoIn theory the failures could be pretty insidious - data could be corrupted without any crash, or in a way that causes a crash in an almost unrelated part of the program. I have no idea how likely the really squirrelly failure modes are, but there will be much scratching of heads and gnashing of teeth when they do pop up. The race detector probably helps a lot.
- bsdetector 11y agoIn the future some Go programs may fail or perform really badly (not exit for minutes) with GOMAXPROCS=1. Since Go isn't preemptively scheduled if you have a goroutine in a long-running or busy loop the program will run normally using 2 CPUs and freeze with 1. Even well-written programs can become "chunky" with 1 CPU and exhibit huge latency spikes not seen with 2 CPUs. Because of M:N threading.
- pcwalton 11y agoIt's sort of preemptively scheduled on function call boundaries now, isn't it?
- bsdetector 11y agoThere was preemption in some places. I thought it was when the stack grew or shrank, but who knows. Checking at every function call seems like a huge waste. This probably won't cause anywhere near as many problems as >1 CPU, but still since VMs sometimes have 1 CPU and almost no developer computers have 1 CPU I expect it will not be unheard of.