What is the difference between user-level threads and kernel-level threads?
User-level threads are managed by a library in user space, and the kernel sees only one process. Kernel-level threads are managed by the OS itself, so they can run on several cores and block independently.
Explain it simply
Think of a team inside one office. With user-level threads, the team manager (a library) decides who works next, and building security (the kernel) only knows "one team is inside". With kernel-level threads, security knows every person individually and assigns each a desk.
User-level threads
- Created and switched by a library with no system call, so they are fast and cheap.
- The kernel sees one schedulable unit. If one thread makes a blocking call, the whole process blocks.
- Cannot use multiple cores at the same time.
Kernel-level threads
- Created and scheduled by the OS, so management costs a system call.
- A blocked thread does not stop its siblings.
- Different threads can run on different cores in parallel.
Example
Suppose a process has two user-level threads A and B. Thread A calls read() on a slow disk. The kernel sees the process asking for I/O and blocks the whole process, so B cannot run even though it has work to do.
With kernel-level threads, the kernel blocks only A and schedules B on the CPU.
Modern systems (Linux, Windows, macOS) use kernel-level threads, usually one kernel thread per application thread. This is called the one-to-one model.
What to say in the interview
"User-level threads are handled by a library and are cheap, but one blocking call blocks the whole process and they cannot use multiple cores. Kernel-level threads cost more to manage but run in parallel and block independently. Mainstream OSes use the one-to-one kernel thread model."
Common mistakes
- Saying user-level threads can run in parallel on multiple cores.