Learn the vocabulary of scheduling thousands of lightweight, cooperatively scheduled threads in user space.
0 / 5 completed
1 / 5
A teammate explains that a runtime schedules thousands of lightweight, cooperatively scheduled units of execution entirely in user space, multiplexing them onto a small number of operating-system threads instead of the kernel scheduling each one directly. What is this concurrency abstraction called?
Green threads are exactly this: a user-space runtime schedules many lightweight threads cooperatively and multiplexes them onto a small number of real operating-system threads, avoiding the per-thread kernel overhead of one OS thread per unit of work. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This user-space-scheduling approach is exactly why green threads can support far higher concurrency than one-OS-thread-per-task designs.
2 / 5
During a design review, the team adopts green threads for a server handling hundreds of thousands of concurrent connections, specifically because spawning a green thread per connection costs kilobytes instead of the megabytes an OS thread would cost. Which capability does this provide?
Green threads here provide massively higher concurrency at lower memory and context-switch cost, since they are scheduled in user space with much smaller stacks and cheaper switches than OS threads. Spawning one OS thread per connection at the megabyte-scale stack size an OS thread typically needs would exhaust memory and kernel scheduling capacity long before hundreds of thousands of connections were reached. This cheap-lightweight-unit behavior is exactly why green threads are favored for massively concurrent I/O-bound servers.
3 / 5
In a code review, a dev notices a server spawns one real operating-system thread per incoming connection, and the process runs out of memory once concurrent connections reach the tens of thousands, instead of using green threads multiplexed onto a small OS thread pool. What does this represent?
This is a missed green-threads opportunity, since multiplexing lightweight threads onto a small OS thread pool would support far more concurrent connections at a fraction of the memory. A cache eviction policy is an unrelated concept about discarded cache entries. This one-OS-thread-per-connection pattern is exactly the kind of scalability ceiling a reviewer flags once connection counts are expected to reach the tens of thousands.
4 / 5
An incident report shows a server crashed with an out-of-memory error once concurrent connections passed fifty thousand, because each connection held its own dedicated operating-system thread with a multi-megabyte stack. What practice would prevent this?
Switching the server to green threads multiplexed onto a small pool of OS threads makes each connection's lightweight stack cost kilobytes instead of megabytes. Continuing to spawn one dedicated OS thread per connection regardless of how much memory the growing connection count consumes is exactly what caused the out-of-memory crash described in this incident. This lightweight-multiplexed-thread approach is the standard fix once OS-thread-per-connection is confirmed to exhaust memory at scale.
5 / 5
During a PR review, a teammate asks why the team reaches for green threads instead of just using operating-system threads directly, given that OS threads integrate more simply with existing blocking system calls. What is the reasoning?
Green threads trade some integration complexity around blocking calls for vastly cheaper concurrency at scale, while OS threads integrate simply with blocking calls but become expensive in memory and context-switch cost as thread counts grow very large. This is exactly why green threads are favored for servers needing extremely high connection concurrency, while OS threads remain simpler and acceptable when concurrency stays modest.