green threads

Suppose you want the feeling of having hundreds of helpers but cannot afford to hire and house hundreds of real employees. Instead you keep a few real workers and a clever clipboard that lets one worker pause one imaginary helper's job and pick up another's, instantly. Green threads are that clipboard for programs: threads created and scheduled by a language runtime or library in user space, not by the operating-system kernel — so you can have huge numbers of them at tiny cost.

Concretely, green threads (and their close relatives, fibers) are managed entirely above the kernel. The runtime keeps each green thread's stack and saved state and switches among them in user space, without a system call, which makes creating and switching them far cheaper than kernel threads — cheap enough to run hundreds of thousands at once. Because the kernel does not see them, classic green threads sit on the many-to-one or many-to-many model. Modern systems improved the design: Go's goroutines and similar lightweight tasks run a user-space scheduler over a small pool of kernel threads (an M:N arrangement) and cooperate with the runtime so that a blocking operation parks just one task and lets another run.

The honest trade-offs follow from staying out of the kernel. In the simplest (many-to-one) form, green threads cannot use more than one CPU core, and a blocking system call by one can stall them all — exactly the user-level-thread weakness. The modern M:N runtimes fix both, but at the price of a sophisticated runtime that must intercept blocking calls and balance work across kernel threads. The win is enormous scale and cheap switching, ideal for programs juggling tens of thousands of mostly-waiting tasks (network servers); they are not a free upgrade for raw CPU-bound parallelism, which still ultimately needs kernel threads on multiple cores.