Multithreading

Overview Concurrency and parallelism are often used interchangeably, but they describe different things: concurrency is about interleaving multiple tasks so a program can make progress on all of them, while parallelism is about simultaneous execution of tasks on separate hardware. A single-core CPU can be concurrent but never truly parallel; a multi-core CPU can be both. Comparison Diagram ConcurrencyParallelism1 CPU CoreABACBtime (single lane, tasks interleave)only one task runs at any instantCore 1Core 2Core 3ABCtime (all run at once)tasks execute simultaneously Comparison Table Aspect Concurrency Parallelism Core definition Structuring a program to make progress on multiple tasks by interleaving them Executing multiple tasks or subtasks at the literal same instant Hardware requirement Works on a single core via context switching Requires multiple cores, processors, or SIMD units Execution pattern Tasks take turns; interleaved progress, order not guaranteed Tasks run simultaneously on separate execution units Task independence Tasks often share state and need coordination to interleave safely Tasks are usually split to run independently, minimizing interference Primary goal Improve responsiveness and structure for handling many things at once Improve throughput by doing more work in the same time Typical workload I/O-bound: network calls, file access, user events CPU-bound: numerical computation, data processing Common pitfalls Race conditions, deadlocks, callback/coordination complexity Synchronization overhead, diminishing returns (Amdahl’s law) Language/runtime constructs Event loops, coroutines, async/await, green threads OS threads, multiprocessing, GPU kernels, SIMD Key Differences Concurrency is a way of structuring code to deal with multiple tasks; it doesn’t require them to run at the same instant. Parallelism requires multiple cores executing work simultaneously, while concurrency runs fine on a single core. Concurrent code can run without being parallel, and parallel code (like SIMD data processing) can run without concurrent structure. Concurrency’s main hazard is a race condition from shared state; parallelism’s main cost is synchronization overhead. Concurrency optimizes for responsiveness; parallelism optimizes for raw computational throughput. When to Use Each Concurrency ...

Overview A process is an independently executing program instance with its own private address space, while a thread is a lightweight unit of execution that runs inside a process and shares that process’s memory with its sibling threads. The distinction matters because it determines how much isolation, communication overhead, and crash-safety you get versus how cheap context switching and data sharing are. Comparison Diagram Process Thread Process A Code Data Heap Stack Process B Code Data Heap Stack no shared memory (IPC only) single process address space Shared Code / Data / Heap Thread 1 Stack Registers Thread 2 Stack Registers Thread 3 Stack Registers shared heap/code, private stack per thread Comparison Table Aspect Process Thread Memory space Own isolated virtual address space Shares address space with sibling threads in the same process Creation cost Expensive (fork/CreateProcess, new page tables) Cheap (allocate stack + TCB, reuse existing address space) Context switch cost Higher (flush TLB, swap page tables) Lower (same address space, just swap registers/stack pointer) Communication Requires IPC: pipes, sockets, shared memory, message queues Direct via shared variables/heap; needs locks/mutexes for safety Fault isolation A crash typically stays contained to that process A crash (e.g. bad pointer, unhandled exception) can take down the whole process Scheduling unit OS schedules processes (which contain ≥ 1 thread) OS (or runtime) schedules threads independently within a process Concurrency primitives needed Rarely needed within a single process Mutexes, semaphores, atomics to guard shared state Typical use case Running separate, independently-failing programs (browser tabs as processes, microservices) Parallelizing work within one program (web server handling many requests, UI thread + workers) Key Differences A thread lives inside a process and shares its code, heap, and open file handles; a process owns its own private address space. Threads communicate by directly reading/writing shared memory (needing synchronization); processes must use explicit IPC mechanisms. Creating and context-switching a thread is much cheaper than doing the same for a process, since no new address space or page table is involved. A crashing thread can corrupt or kill its entire parent process; a crashing process is generally isolated from other processes by the OS. Multiple threads share one process’s resource limits (file descriptors, memory quota); each process gets its own. When to Use Each Process ...