Unraveling Linux Threads: From Classic Processes to NPTL and Beyond

Understanding Linux Threads

Classic OS textbooks define a process as an instance of a program that holds static resources, while a thread is the actual execution entity. A process must contain at least one thread.

Static resources include address space, open file descriptors, file system state, signal handlers, etc. Dynamic resources maintained by a thread include its stack, scheduling information, pending signals, and so on.

Linux’s Lack of a Native Thread Concept

Historically the Linux kernel treated every execution entity as a task_struct, commonly called a process. The kernel introduced the notion of lightweight processes (LWP) to represent threads, created via the clone system call with selective sharing of resources.

POSIX requires that a group of related task_struct objects appear as a single process in listings, share signals appropriately, and be managed as a unit.

linuxthreads Library (Pre‑2.6)

Before kernel 2.6, the pthread implementation was provided by the “linuxthreads” library, which used LWPs but failed to satisfy most POSIX requirements except the ability to terminate the entire process when a thread crashes. It introduced a management thread that created and monitored other threads, becoming a performance bottleneck.

Native POSIX Thread Library (NPTL) – Kernel 2.6+

Kernel 2.6 added thread groups, adding a tgid (thread group ID) to task_struct. The main thread’s tgid equals its PID; all other threads share the same tgid. Passing CLONE_THREAD to clone makes the new task join the parent’s thread group.

Signals sent to the process are placed in a shared signal_pending queue, while pthread_kill signals go to a thread‑specific queue, ensuring correct delivery semantics. The kernel also maps getpid() to tgid and gettid() to the individual thread’s PID.

Next Generation POSIX Threads (NGPT)

NGPT aims to implement an M:N threading model, where many user‑level threads are multiplexed onto fewer kernel threads. This would use user‑level context switches (e.g., setjmp/longjmp) for speed, but sacrifices true parallelism on multi‑core systems. The model has been realized in some UNIX systems like Solaris, though Linux has not adopted it.