Multithreading & concurrency explained

Threads vs processes

A process is a running program with its own isolated memory. A thread is a unit of execution inside a process; threads in the same process share memory. That shared memory is what makes threads cheap to communicate, and also what makes concurrency hard, multiple threads reading and writing the same data at once is the root of most concurrency bugs.

Concurrency vs parallelism

They are different. Concurrency is structuring a program as independent tasks that can make progress in overlapping time periods. Parallelism is actually running tasks at the same instant on multiple CPU cores. You can have concurrency on a single core (the scheduler interleaves tasks); parallelism needs multiple cores. Concurrency is about design; parallelism is about execution.

Race conditions

A race condition happens when the result depends on the unpredictable timing of threads. The classic example is two threads incrementing a shared counter: read, add 1, write back is three steps, and if both read the same value before either writes, one increment is lost.

import threading

counter = 0

def work():
    global counter
    for _ in range(100_000):
        counter += 1            # read, add, write: three steps, NOT atomic

threads = [threading.Thread(target=work) for _ in range(4)]
for t in threads: t.start()
for t in threads: t.join()

print(counter)                  # expected 400000, but often less: a race

The bug is intermittent and timing-dependent, which is why concurrency bugs are so hard to reproduce.

Locks, mutexes, and deadlocks

The fix is to make the dangerous sequence atomic, indivisible. A lock (or mutex, “mutual exclusion”) ensures only one thread enters a critical section at a time; others wait.

lock = threading.Lock()

def safe_work():
    global counter
    for _ in range(100_000):
        with lock:              # only one thread inside at a time
            counter += 1        # now the increment is atomic

Hold locks for as short a time as possible: locking too much serializes your program and kills the benefit of threads; locking too little leaves races open. And beware the deadlock, threads waiting on each other forever (A holds lock 1 and wants lock 2 while B holds lock 2 and wants lock 1). The standard prevention is to always acquire multiple locks in the same global order, hold as few at once as possible, and use timeouts so a stuck acquisition fails loudly instead of hanging.

Writing thread-safe code

• Don’t share mutable state if you can avoid it, the safest shared data is no shared data.
• Prefer immutability: data that never changes after creation is automatically thread-safe.
• Use higher-level tools: thread-safe collections, atomic types, and message-passing (queues or channels) are easier to get right than hand-rolled locks.
• Protect every access to shared mutable data with the same lock, guarding only some accesses still races.

Async vs threads (and the GIL)

Not all concurrency needs threads. For I/O-bound work, waiting on the network, disk, or a database, async / non-blocking models (event loops, async/await) let a single thread juggle thousands of in-flight operations without the overhead and locking of real threads.

One language-specific gotcha: in CPython (the standard Python interpreter), a Global Interpreter Lock (GIL) lets only one thread run Python bytecode at a time, so threads do not give you CPU parallelism for pure-Python work, reach for multiprocessing there. Threads still help I/O-bound Python because the GIL is released while waiting. (Newer CPython is adding an optional free-threaded build that relaxes this.)

FAQ

Related concepts

OOP concepts · Memory leaks · Smart pointers · Design patterns · all references.