Concurrency lets a system deal with more than one task during overlapping periods. Like one cook alternating between stirring soup and chopping vegetables, tasks can all make progress even when only one processing resource is available. They need not run at the exact same instant. section 1.0 section 2.13
Concurrent programming breaks an application into independent tasks and lets a runtime system organize their execution. Tasks may be called coroutines, processes, or threads; the runtime system maps them onto available processing resources while the developer focuses on the work and its coordination. section 4.1 section 13.1
Concurrency helps when work has one or more of these needs:
- Improve throughput by keeping resources busy, reducing or hiding latency, and handling more work over time. section 1.2 section 1.6
- Scale out by distributing load across additional processors or interconnected machines. section 1.3 section 1.6
- Decouple a large problem into smaller communicating units with clearer responsibilities. section 1.3
- Serve overlapping network activity, such as multiple clients that would otherwise wait behind one blocked connection. section 10.5
Concurrency is not automatically parallelism or a speedup. Concurrency concerns tasks whose lifetimes overlap; parallelism is their physically simultaneous execution on multiple computing resources. A single core can create concurrent progress through multitasking and fast switching, while multiple cores can execute suitable tasks in parallel. section 2.13 section 6.8
Think in layers. At the application layer, algorithms describe what should happen. At the runtime layer, an operating system schedules processes and threads. At the hardware layer, processing resources execute instructions. The same work can look different at each layer, and concurrent execution can exist even on a sequential machine. section 1.4 section 4.0
Password cracking in chunks
A sequential password search can be split into chunks and assigned to a worker pool. Each worker checks a different range concurrently; with available CPU cores, the demonstrated version achieves more than a threefold speedup. This is a useful pattern for independent CPU-bound work, not a promise that every concurrent design will be faster. section 5.5
Independence is the goal, not a guarantee. When tasks share resources, timing is outside the developer’s full control: stale reads can produce inconsistent updates, tasks can deadlock, and distributed data may fail to converge. Designing a concurrent system therefore includes coordinating shared resources and checking efficiency and scalability. section 13.1 section 13.0
