Thread

A thread is the smallest unit of CPU scheduling within a process — an independent flow of execution that shares the process's address space and resources while maintaining its own program counter, register set, and stack. Where a process is a container of resources and a security boundary, a thread is a unit of concurrency: the mechanism by which a single program performs multiple operations simultaneously.

Threads emerged as a lighter alternative to processes. Creating a process requires copying or mapping the entire address space; creating a thread requires only allocating a new stack and a small control block. Threads communicate through shared memory rather than slow inter-process communication mechanisms, enabling fine-grained parallelism and responsive user interfaces. But this sharing is also the thread's danger: because threads access the same memory, they can corrupt each other's data through race conditions, produce inconsistent states through unsynchronized access, and create bugs that are intermittent and nearly impossible to reproduce.

The thread abstraction has shaped programming language design, operating system architecture, and hardware evolution. Mutexes, semaphores, condition variables, and monitors are synchronization primitives invented specifically to manage thread interactions. Modern CPUs include atomic instructions and memory models designed to support multi-threaded programs. The entire field of concurrent programming is, in a sense, the study of how to use threads safely.

The thread is the most dangerous abstraction in computing because it appears simple. It is just another flow of control, the programmer thinks, like a function call. But a function call is synchronous and deterministic; a thread is asynchronous and non-deterministic. The gap between these two models is where most concurrent bugs are born. The thread does not add complexity to a program. It reveals the complexity that was always there, hidden by the illusion of sequential execution.