In computer science, synchronization is the coordination of concurrent activities so that their interactions satisfy specified ordering and shared-resource constraints. It can prevent conflicting accesses, make one activity wait for another, and ensure that changes to shared state become visible where required. Synchronization is central to concurrent computing and parallel computing; it does not necessarily mean that activities execute simultaneously or at the same speed. (pubs.opengroup.org)
Purpose and scope
Synchronization addresses several related requirements:
- Exclusive access: preventing incompatible operations on a shared resource from overlapping.
- Execution ordering: ensuring that an operation occurs only after a prerequisite has completed.
- Memory visibility: establishing which writes one execution context is guaranteed to observe.
- Collective coordination: requiring a group of participants to reach a specified stage before proceeding. (pubs.opengroup.org)
These requirements arise both when activities are interleaved on one processor and when they execute on different processors. A single processor does not eliminate synchronization problems: one activity can be interrupted between steps of an operation, allowing another to access the same state. (cdn.kernel.org)
In shared-memory systems, synchronization commonly coordinates threads through locks and other shared objects. In distributed computing, participants can coordinate through message exchanges and collective operations, such as barriers. The guarantees depend on the communication interface rather than on a shared address space. (pubs.opengroup.org)
Shared state and conflicting operations
A critical section is a region of execution that accesses state whose integrity requires controlled access. Mutual exclusion permits only one participant at a time to execute regions protected by the same exclusive lock. The protection works only when all relevant accesses follow the same synchronization protocol; acquiring an unrelated lock does not protect the state. (cdn.kernel.org)
For example, an increment such as counter++ may consist of reading a value, adding one, and storing the result. If two threads both read the same original value before either stores its result, one increment can be lost. Protecting the entire read–modify–write sequence with a lock, or using an appropriate atomic increment, prevents that particular interference. (docs.oracle.com)
A data race concerns conflicting memory accesses that lack the ordering or atomicity required by the applicable memory model. A race condition is a broader problem in which correctness depends on an uncontrolled ordering of events. Eliminating data races does not automatically make a multi-step protocol correct: individually protected operations may still need to form one indivisible transaction. (pubs.opengroup.org)
Synchronization mechanisms
Locks
A mutex, or mutual-exclusion lock, grants exclusive ownership until released. Other participants attempting to acquire it may wait. A readers–writer lock permits multiple readers together but requires exclusive access for a writer, allowing concurrent reads when the protected state is not being modified. (pubs.opengroup.org)
A spinlock waits by repeatedly attempting acquisition rather than suspending the waiting execution context. Blocking locks can suspend a waiter so that the processor performs other work. Their relative costs depend on contention, waiting duration, scheduling, and implementation; spinning consumes processor time while waiting. (cdn.kernel.org)
Semaphores and condition variables
A semaphore maintains a count of permits. An acquisition consumes a permit, waiting when none is available; a release supplies a permit. Counting semaphores can limit simultaneous use of a resource, rather than restricting access to a single participant. (docs.oracle.com)
A condition variable allows a thread to wait until a predicate over shared state may have become true—for example, until a queue is nonempty. In POSIX, waiting atomically releases the associated mutex and blocks the caller; returning from the wait reacquires that mutex. A wake-up does not prove that the predicate is true, so the predicate is checked again, normally in a loop. This also accommodates spurious wake-ups. (pubs.opengroup.org)
Barriers and completion objects
A barrier coordinates a group at a designated execution point. For example, an MPI barrier on an intracommunicator does not return to any participant until every member has entered the call. It separates phases of computation without requiring participants to arrive at exactly the same instant. (mpi-forum.org)
Other abstractions express more specific dependencies. A countdown latch waits for a set of events; a future represents a result that may become available later. These mechanisms coordinate completion without necessarily granting exclusive access to shared state. (docs.oracle.com)
Atomic operations and message passing
An atomic operation performs an access or update indivisibly with respect to the relevant concurrent operations. Atomic read–modify–write operations support counters and more elaborate concurrent algorithms. Atomicity and memory ordering are distinct: in C++, relaxed atomic operations do not themselves establish synchronization for unrelated memory accesses. (docs.oracle.com)
Message passing can combine communication with synchronization. In Go, for example, a channel send is synchronized before completion of its corresponding receive. Such ordering can make earlier writes visible to the receiving activity. Buffered and unbuffered communication have different guarantees, so message exchange does not imply one universal synchronization behavior. (go.dev)
Memory ordering
A memory model specifies the permitted observations of memory operations across execution contexts. Source-code order alone does not necessarily establish the ordering another thread needs to observe. Synchronization operations impose defined constraints on those observations. (pubs.opengroup.org)
Many models describe these constraints through a happens-before relation. This combines ordering within an execution context with ordering established by synchronization between contexts. For example, releasing a mutex and subsequently acquiring that mutex can establish visibility of writes made within the preceding protected region. The precise rules belong to the relevant language or interface specification. (pubs.opengroup.org)
An execution barrier and a memory-ordering mechanism therefore should not be treated as interchangeable. Waiting for participants to reach a point and ensuring visibility of particular memory or storage updates are separate guarantees; an interface may require additional operations to provide both. (mpi-forum.org)
Progress failures and performance
Synchronization can preserve shared-state integrity while still preventing useful progress:
- Deadlock: participants wait on resources held by one another, preventing further progress.
- Starvation: a participant repeatedly fails to obtain the resources needed to proceed.
- Livelock: participants remain active and respond to one another but accomplish no useful work. (docs.oracle.com)
Synchronization also introduces overhead and can reduce available parallelism. A highly contended lock serializes access to its protected region. Dividing protection among more locks can allow greater concurrency, but increases the complexity of coordinating accesses and avoiding deadlock. Consequently, synchronization granularity is a trade-off between coordination cost, parallelism, and correctness complexity. (cdn.kernel.org)
Related uses of the term
Clock synchronization concerns aligning clocks rather than directly protecting shared data or ordering program operations. The Network Time Protocol exchanges timekeeping information to synchronize system clocks across networked clients and servers. This is a distinct use of synchronization from locks, condition variables, and barriers. (rfc-editor.org)
References
- General Conceptspubs.opengroup.org
- The Go Memory Modelgo.dev
- System Interfaces Chapter 2pubs.opengroup.org
- Thread Interferencedocs.oracle.com
- Locking lessonscdn.kernel.org
- Unreliable Guide To Lockingcdn.kernel.org
- Debugging Multithreaded Programsoracle.com
- Multithreaded Programming Guidedocs.oracle.com
- pthread_cond_clockwaitpubs.opengroup.org
- Barrier Synchronizationmpi-forum.org
- java.util.concurrent (Java SE 25 & JDK 25)docs.oracle.com
- C++ International Standardisocpp.org