the one-to-one model
Now give every worker on the team their own dedicated phone line. Each person can dial out independently, and if one gets stuck on hold the others keep calling — nobody is blocked by anybody else. The one-to-one model maps each user-level thread to its very own kernel thread. The kernel sees every thread individually and can schedule each one on its own.
Concretely, in one-to-one, the moment your program creates a thread, the OS creates a matching kernel thread, paired one for one. Because each thread is a separate kernel-schedulable entity, the kernel can place different threads of the same process onto different CPU cores simultaneously, giving real parallelism. And if one thread makes a blocking system call, the kernel simply runs another of the process's threads, so the rest keep going. This directness is why one-to-one is the model used by Linux, Windows, and most modern systems.
The cost is the trade-off built into the pairing: creating a user thread now means creating a kernel thread, which is a heavier kernel operation than a pure user-space switch, and every kernel thread consumes kernel resources. Because of this, systems often cap how many threads a process may create, and spawning threads carelessly (one per tiny task) wastes time and memory — which is precisely the problem the thread pool pattern solves. Compared with many-to-one you gain parallelism and block-resilience; compared with many-to-many you trade some flexibility and a slightly higher per-thread cost for simplicity.
On Linux, calling pthread_create() makes the kernel create a new schedulable thread one-for-one. A four-thread compute job then truly spreads across four cores, and when thread A blocks reading a file, threads B, C, and D carry on — exactly what many-to-one could not do.
Each thread its own kernel thread — true parallelism, at the cost of heavier creation.
One-to-one gives real parallelism and block-resilience, but each thread is a kernel thread, so creating thousands is costly — many systems limit thread counts, which is why thread pools matter.