Concurrency is a way to structure a program as separate tasks that can make progress during overlapping periods. The tasks may truly run at once on multiple processing units, or they may be interleaved on one processor. It fits software that must model simultaneous activity: orders arriving together, shipments being consolidated while deliveries continue, or payroll calculations across many employees. section 1.1 section 1.2 section 2.4
Start by identifying independent units of work and their boundaries: handling one request, searching one file, calculating one matrix row, or rendering one game frame. Concurrency plans those tasks and their synchronization points; parallelism is the runtime result when hardware can execute more than one task simultaneously. A concurrent design can still help on a single processor by switching among tasks rather than blocking the whole program. section 2.4 section 1.4
Concurrency is useful for several related goals:
- Increase throughput on multiple processors by distributing suitable work across available processing resources. section 1.3
- Use otherwise idle CPU time while another operation waits for disk, network, keyboard input, or other I/O. section 1.3
- Keep interactive software responsive by handling input while background work such as spell checking, statistics, and autosaving proceeds. section 1.4
- Model business activity in which multiple actors affect shared resources or state at nearly the same time. section 1.2
A shipment-consolidation workflow makes the central design problem visible: several activities overlap, coordinate, and can affect one another. section 1.2
Concurrency is not automatically a speedup. Extra processors help only when code can use them, and fixed-size work remains limited by portions that cannot run in parallel. Interleaving also introduces coordination problems: concurrent executions can step on each other, and shared-variable updates can produce race conditions. Completion must be coordinated too; ending the main Go goroutine terminates the process even when other goroutines are still running. section 1.7 section 3.2.3
Counting letters from many web pages
A sequential letter counter downloads and processes 31 documents one after another. A concurrent version starts one goroutine per document, so downloads and processing overlap. Its output completes URLs in a different order and finishes sooner in the shown run, but the shared frequency slice yields incorrect totals because multiple goroutines update it without safe coordination. Sleeping to wait for completion is also unreliable; synchronization should replace a guessed delay. section 3.2.3
Divide work, then stop the group
A brute-force search divides a password-guess range among goroutines. Each checks a shared stop channel while working. When one finds the answer, it sends the result and closes that channel, broadcasting a stop signal so the other goroutines can avoid further computation. This shows concurrency as both work partitioning and deliberate communication. section 8.1.3
In Go, goroutines model lightweight concurrent executions. Channels provide a way for executions to communicate and synchronize. Designs can emphasize message passing in a communicating sequential processes style or use classical shared-memory primitives; the choice affects both the fit for a problem and the kinds of errors a design is likely to invite. section 1.5 section 1.7
