Concurrent computing is an approach to computer science in which multiple computational activities make progress during overlapping periods. A concurrent system contains components whose execution need not follow a single, predetermined sequence. These components may communicate, share resources, and coordinate their actions. Concurrency does not require simultaneous execution: activities can interleave on one processor or run simultaneously on several. Its central concerns are the organization of independently executing components and the correctness of their interactions. (go.dev)
Concurrency, parallelism, and distribution
Concurrency and parallel computing describe related but distinct aspects of computation. Concurrency concerns how a program is structured around activities that can progress independently; parallelism concerns executing computations simultaneously. A concurrent program can operate without parallel execution, while its structure may allow parallel execution when sufficient hardware and independent work are available. Adding concurrent components does not automatically make a computation faster. (go.dev)
Distributed computing involves components that communicate across a system, commonly through messages between separate computers. Such systems exhibit concurrency because events in different components may lack a common execution order. In his 1978 paper on event ordering, Leslie Lamport formalized a “happened-before” relation that defines a partial order: some events are ordered by local execution or communication, whereas others are concurrent in the sense that neither precedes the other under that relation. (lamport.azurewebsites.net)
Execution mechanisms
Concurrent activities can be represented by processes, threads, or tasks managed by a runtime. Threads within a program can operate on shared objects. An operating system or runtime can support their execution through multiple processors, by time-slicing one processor, or by combining both mechanisms. Thus, the number of active threads need not equal the number of computations executing simultaneously. (docs.oracle.com)
Asynchronous programming provides another way to organize overlapping work. In an event loop, tasks can suspend while waiting for an operation and resume when its result becomes available. Python’s asyncio, for example, uses cooperative scheduling: its loop runs one task at a time, but can run other tasks or callbacks while a task awaits a future. Coroutines therefore support concurrency without necessarily introducing parallel execution. (docs.python.org)
Execution mechanisms are distinct from application structure. A server may organize work around incoming requests, while a computational pipeline organizes it around successive processing stages. Go’s official documentation illustrates both independently executing components and channel-based request handling, showing how communication can express relationships between concurrent activities. (go.dev)
Communication and synchronization
Two important approaches to interaction are shared memory and message passing. With shared memory, activities communicate by reading and modifying common data. With message passing, they exchange values through communication mechanisms such as channels. These approaches can coexist: Go provides channels but also supports shared-memory coordination, and its documentation explicitly notes situations in which a mutex is appropriate. (go.dev)
Synchronization constrains execution order or access to resources. A mutex provides mutual exclusion, allowing only one participating activity at a time to execute a protected critical section. A semaphore manages permits, while barriers coordinate activities at a common execution point. Higher-level facilities include concurrent collections, executors, and futures, which organize shared access, task execution, and results. (docs.oracle.com)
Synchronization also governs visibility. A memory model specifies which writes a read may observe and what ordering guarantees particular operations provide. Consequently, correctness requires more than preventing visibly simultaneous updates: a program must also establish the necessary relationships between writes and subsequent reads. Java’s memory model explicitly defines such constraints for multithreaded execution. (docs.oracle.com)
Correctness and failure modes
A race condition occurs when correctness depends on an uncontrolled ordering of operations. For example, an increment can consist of reading a counter, adding one, and storing the result. If two activities both read the same value before either stores its update, one update may overwrite the other. A simple-looking expression is therefore not necessarily an indivisible operation. (docs.oracle.com)
A data race is a more specific problem involving conflicting memory accesses that are not adequately ordered by synchronization. Avoiding data races does not settle every coordination problem: a sequence of individually protected operations may still fail to preserve an application-level requirement. Concurrent algorithms must therefore be evaluated against their complete specifications, rather than only the safety of individual accesses. (docs.oracle.com)
Progress failures include deadlock, in which activities cannot proceed because of unresolved waiting dependencies; starvation, in which an activity repeatedly fails to obtain needed resources; and livelock, in which activities continue responding to one another without accomplishing useful work. Starvation and livelock differ from simple inactivity because other execution may continue while the affected work makes no progress. (docs.oracle.com)
Specification and verification
Correctness properties are commonly divided into safety and liveness. Safety excludes unacceptable behavior, such as two activities entering a mutually exclusive section together. Liveness requires eventual progress, such as termination or eventual service of a request. Mutual exclusion alone does not guarantee progress: a system in which no activity ever enters its critical section satisfies exclusion but may accomplish nothing. (lamport.azurewebsites.net)
Formal verification can represent a concurrent system as a state machine and check whether its possible behaviors satisfy specified properties. Verification may also require fairness assumptions about which enabled activities eventually execute. Languages such as TLA+ express both system behavior and properties mathematically, allowing implementation relationships, invariants, and progress requirements to be examined explicitly. (lamport.azurewebsites.net)
References
- Concurrency is not parallelism - The Go Programming Languagego.dev
- Threads and Locksdocs.oracle.com
- Effective Go - The Go Programming Languagego.dev
- Time, Clocks, and the Ordering of Events in a Distributed Systemlamport.azurewebsites.net
- Coroutines and tasks — Python documentationdocs.python.org
- Effective Go - The Go Programming Languagego.dev
- java.util.concurrent (Java SE 25 & JDK 25)docs.oracle.com
- Thread Interferencedocs.oracle.com
- Starvation and Livelockdocs.oracle.com
- PlusCal Tutorial - Session 9lamport.azurewebsites.net
- A High-Level View of TLA+lamport.azurewebsites.net