[mkup]

Go runtime library contains user-space scheduler which maps lightweight Go threads to heavyweight OS threads in M:N manner. By the way, Go runtime library allows running user code in only one OS thread per process, all other OS threads must be in the state of blocking system call. So, no mutexes / interlocked instructions are required to access global data from goroutines, but this comes at the cost of reduced parallelism compared to C/C++ (which author of original article seems to be unaware of).

[aws_ls]

I doubt if this is totally true. Upto Go version 1.4, the process would use only 1 core/cpu per process by default, but you could change it by:

numCPU := runtime.NumCPU()

ret := runtime.GOMAXPROCS(numCPU)

From 1.5 the process the default value of MAXPROCS is total CPUs on the machine.

So its not 'reduced parallelism compared to C/C++' rather the concurrency infrastructure (channels etc) makes it transparent to the programmer. I don't have to worry about creating a threadpool myself like C/C++ and Java. So overall there is a net gain, in my understanding. Am I wrong any where in this?

[NateDad]

Wow, uh no. You're 100% wrong, unless I'm misunderstanding you. You can absolutely have user code running on N threads simultaneously (where N is the number of cores of your machine). And you definitely do need mutexes.

Your statement holds only if GOMAXPROCS is 1, which granted used to be the default, but was always able to be increased, and the default now is the number of cores on the machine.

[mkup]

Ah, now I see these things changed recently. I wrote original comment because at the time of Go 1.1 or 1.2 my colleague wrote racy code which accessed global variable without mutexes. I tried to educate him to use mutexes, by reducing his code to the minimal version demonstrating race condition, but failed. Then I digged into the source code of Go runtime library and discovered that only one thread could be in the running state at any moment (other threads could be in the state of blocking system call).

So, things changed since that time. OK, nice to see Go evolves. Interesting, how many code in production got broken during upgrade to Go 1.5 due to this backwards-incompatible change. Overall situation seemed totally reasonable to me at that time: Go is a language for average programmer, so it should prefer safely over runtime performance; and coding cowboys who are comfortable with mutexes, interlocked instructions, memory barrier instructions, and lock-free data structures will use C/C++ anyway.

[tcard]

But that wasn't true either at the time of Go 1.1, nor ever I believe. It was the _default_ behavior to have a single core running at a time, but you could just tweak that with the [GOMAXPROCS](https://godoc.org/runtime#GOMAXPROCS) variable, documented everywhere. (That's what changed in Go 1.5; now the default for GOMAXPROCS is the number of cores in the machine.)