Read on Twitter
Golang really does implement green threads. User code runs on go allocated stacks instead of the default OS stack. It manipulates the stack pointer and program counter to pause and resume execution of goroutines. This logic is architecture specific. #golang
On top of that, it also preempts long running goroutines and yields to the scheduler. That blew my mind a little, I didn't realize that go suspending threads (using OS primitives) and yielded them. This is very much like UMS ( https://channel9.msdn.com/shows/Going+Deep/Dave-Probert-Inside-Windows-7-User-Mode-Scheduler-UMS/) on windows but portable.
This means that golang rarely relies on the OS (to the extent that it can) to manage context switching between goroutines and tries to take complete control all is user mode.
The .NET thread pool on the other hand uses OS threads and the OS stack, so we can't do anything useful with a suspending thread (besides stack scanning by the GC). There are other complications like TLS (thread local storage) that we'd need to handle as well.
