the many-to-one model
Picture a whole team of workers funneling all their phone calls through one shared office phone line. They can take turns and feel like a busy team, but at any moment only one call is actually connected, and if that one line gets stuck on hold, nobody else can call out either. The many-to-one model is this arrangement for threads: many user-level threads are all mapped onto a single kernel thread. The program feels multithreaded, but the kernel sees just one schedulable line.
Concretely, in many-to-one, a user-space library manages many threads and the OS provides exactly one kernel thread for the process. Switching among the user threads happens entirely in user space, which is fast and cheap. But because there is only one underlying kernel thread, the threads share a single connection to the CPU. Thread management — creation, switching, scheduling — is efficient, since it never enters the kernel for an ordinary switch.
The two weaknesses are decisive and follow directly from the single kernel thread. First, if any one user thread issues a blocking system call, the entire process blocks, because the kernel parks its only thread and has no other to run for that process. Second, since the process holds just one kernel thread, it can run on only one CPU core at a time — so even on an eight-core machine, many-to-one threads can never achieve true parallelism. This is why the model has largely been abandoned for general use; it survives mainly as the basis of pure user-level threading and lightweight green-thread libraries where those limits are acceptable.
An early Java implementation used green threads in a many-to-one style: you could create many threads, but they all rode one kernel thread, so a Java program could not use a second CPU core, and one thread blocking on input could stall the rest. Later Java moved to a one-to-one model to fix exactly this.
Many user threads, one kernel thread — no parallelism, and one block freezes all.
Many-to-one can never use more than one core, and a single blocking system call halts the whole process. Its only virtue is the cheapness of switching that stays out of the kernel.