What Is a Thread in Programming?
A thread is the smallest unit of execution that an operating system can schedule — essentially a single sequence of instructions running within a program. A running program (a process) can contain many threads, and those threads can run at the same time, letting one application do several things at once.
Threads vs. Processes
A process is an independent program with its own isolated block of memory. Threads live inside a process and share that process's memory — the code, the heap, and open files — while each thread keeps its own stack and registers. The consequence is twofold: threads are cheaper to create than processes and can communicate almost instantly through shared memory, but that same sharing is the source of the bugs described below.
Concurrency vs. Parallelism
These related terms are easy to confuse. Concurrency means several threads make progress by interleaving — even on a single CPU core, the scheduler rapidly switches between them so they all advance. Parallelism means threads literally execute at the same instant on multiple cores. Threads are the mechanism that enables both: concurrency on one core, true parallelism across many.
Why Use Threads
Threads solve real problems. A desktop or mobile app uses a background thread for slow work so the user interface stays responsive. A web server handles many client requests at once by giving each its own thread (or by reusing a pool of them). And computational tasks split work across threads to use every CPU core and finish faster.
The Risks: Race Conditions and Deadlocks
Because threads share memory, two threads modifying the same data can interleave in a bad order and corrupt it — a race condition, where the outcome depends on unpredictable timing. The fix is synchronization, such as locks or mutexes that let only one thread touch the data at a time. But locks introduce their own hazard: a deadlock, where two threads each wait forever for a lock the other holds. Writing correct multithreaded code is genuinely difficult for this reason.
Threads in Practice
Most languages expose threads directly or through higher-level abstractions like thread pools, async/await, or lightweight tasks (Go's goroutines, for example). One important caveat: some runtimes limit true thread parallelism — CPython's Global Interpreter Lock, for instance, allows only one thread to execute Python bytecode at a time, so CPU-bound work there often uses multiple processes instead. Understanding threads — and the synchronization they demand — is essential for writing software that is both fast and correct on today's multi-core hardware.
Threads sit at the heart of concurrent programming — see how a deadlock arises from locking, how a database transaction handles concurrent access to data, and how a container packages a process and its threads to run anywhere.
Frequently Asked Questions
A process is an independent program with its own isolated memory. Threads run inside a process and share its memory, while each keeps its own stack. Threads are lighter-weight and communicate faster through shared memory, but that sharing is what introduces concurrency bugs like race conditions.
Concurrency is managing multiple tasks that make progress by interleaving — possibly on a single core through rapid switching. Parallelism is executing tasks literally at the same time on multiple cores. Threads can provide either, depending on the hardware and how work is divided.
A race condition occurs when two threads access shared data at the same time and the result depends on the unpredictable order in which their operations run. Synchronization such as locks prevents it, though overusing locks can lead to deadlocks.