Organizing independent activities
A server can wait for network input while processing earlier requests and preparing responses. These activities need not advance in one fixed sequence. Concurrency organizes them as independently progressing tasks, allowing the system to do useful work while another activity is waiting for an external result or event.
References: [1]
Distinguishing concurrency from parallelism
Parallelism concerns computations actually executing at the same time; concurrency concerns their organization. One processor can support concurrency by interleaving tasks, while several processors may run some tasks in parallel. Adding tasks does not guarantee proportional speed: they can compete for one resource or spend their time communicating.
References: [1]
Synchronizing access to shared data
Shared data requires coordination when activities can access the same location and at least one writes it. Locks, channels, and atomic operations can establish ordering guarantees. Source-file order alone does not prove that another task has observed a result. A memory model specifies the guarantees on which such reasoning can rely.
References: [2]
Designing around dependencies
A concurrent design must identify producers, consumers, completion conditions, and failure propagation. Cyclic waiting can prevent progress, and unlimited task creation can exhaust resources. Finding genuinely independent activities and defining their communication boundaries is more useful than multiplying tasks before the dependencies of the work are understood.