SwadhyAI Notes

All Operating Systems notes

Start here

Kernel threads are what the OS scheduler knows about individually. User-level (green) threads can be switched in user space cheaply, but blocking one on a syscall can stall the whole user scheduler unless the runtime cooperates with async I/O or helper pools.

User-level vs kernel-level threads

Kernel-level (1:1) maps each library thread to a kernel schedulable entity (typical Linux NPTL). Blocking in read blocks only that thread.

User-level (many-to-one) multiplexes many user threads on fewer kernel threads; switching avoids syscall overhead but a blocking syscall can pin the only underlying kthread unless the runtime works around it.

By the end of this page you should be able to

  1. State the blocking risk of many-to-one models.
  2. Explain what “kernel visibility” buys you for SMP scaling.
  3. Name one modern technique runtimes use to avoid syscall stalls (e.g. pollers, io_uring).

Hybrid (M:N) tries to combine benefits: many user tasks run on a pool of kernel threads, migrating runnable work when a syscall blocks.

Operating systems · Threads

User-level vs kernel-level threads

Who schedules what

TL;DR

User-level threads are multiplexed in user space without kernel awareness (historical green threads); kernel threads are what the OS scheduler actually dispatches. Models: 1:1 (most pthreads on Linux), M:1, M:N, tradeoff between syscall blocking and scheduler control.

Summary

This topic explains why “I created 100k threads” behaves differently by platform and runtime. Tie answers to blocking points, parallelism, and observability in `top`.

Deeper narrative

User-level threads can switch without syscall overhead but block entirely if one thread blocks in the kernel on a 1:1-less model. Green threads historically lost to blocking I/O; modern runtimes integrate pollers and non-blocking I/O to compensate.

Mechanism (step by step)

Treat each step as a sentence in the story you tell on a whiteboard.
1

User-level scheduler

Runtime picks coroutines without entering kernel, fast yield.

2

Kernel visibility

Without kernel threads, blocking syscall stalls whole user scheduler unless async.

3

Kernel threads

Scheduler balances across CPUs with standard OS fairness and accounting.

4

Hybrid

M:N multiplexors migrate runnable work onto idle kthreads when syscalls block.

Key insights

Each card is a compression of the lesson, use them as spaced-repetition prompts.

Blocking syscalls

If the kernel does not know about user threads, one blocking read stalls the entire user thread runtime unless you shim async I/O.

1:1 simplicity

Each pthread maps to a kernel task, simple, good parallelism, higher memory footprint for huge thread counts.

Scheduler leverage

Kernel-visible threads get fair CPU accounting per cgroup; purely user threads bypass some kernel fairness.

Migration cost

M:N schedulers must carefully pin user threads to kernel threads when crossing cores to preserve locality.

Did you know?

Trivia with teeth: the kind of fact that changes how you reason about a design.
Go uses an M:N model with a network poller to reduce blocking syscall stalls.
Blocking pthread I/O blocks the underlying kernel thread, runtime may need extra threads to keep progress.
Windows historically had fibers (user threads) separate from scheduler-visible threads.

Common pitfalls

Where smart people still trip, read slowly.

Blocking syscall stalls M:N

Must wrap I/O with thread pools or io_uring/async adapters.

Ignoring signal delivery

Signal targeting thread groups differs between models, debug hangs carefully.

Glossary

Green thread

User-space scheduled lightweight thread, kernel may not see it individually.

LWP

Lightweight process, Solaris term for kernel-visible thread backing user threads.

Poller

Event loop using epoll/kqueue to drive many sockets without blocking pool.

Interview follow-ups

  1. Why did early green threads lose to pthreads for server workloads?
  2. What does `gettid` reveal under NPTL?
  3. How does async/await relate to kernel scheduling?

Callouts

Interview trap

Do not claim green threads always avoid kernel, modern runtimes park goroutines onto threads that block.

Walkthrough & deep dive

Left: practical “how would I use this?” threads. Right: slower, code-leaning explanations, open one panel at a time so the page does not feel like a wall of sameness.

Walkthrough

Compare

Contrast Java virtual threads (project Loom) with classic 1:1 pthreads in terms of carrier threads.

Deep dive

Scheduler activation (historical)

Kernel upcalls could unblock user-level schedulers, complex; largely replaced by better 1:1 kernels and io_uring.

Kernel threads visible

Terminal
ps -eLo pid,tid,class,rtprio,comm | head

Self-check

Misses here are cheap; misses in an interview are not. Treat wrong answers as a patch list for tomorrow.

1Kernel threads are scheduled by…

2Pure M:1 user threads struggle when…

3Linux pthreads are typically…