Concurrency¶

Prime #: 157
Origin domain: Computer Science & Software Engineering
Also from: Operations Research, Biology & Ecology, Organizational & Management Science
Aliases: Parallelism, Simultaneous Processing
Related primes: Deadlock, Pipeline, Synchronization

Core Idea¶

Concurrency is the ability of a system to manage multiple independent or interdependent processes occurring simultaneously, often requiring explicit coordination, synchronization, or conflict resolution. The essential commitment is that separate loci of execution or activity proceed in time-overlapping fashion, raising questions of ordering, resource contention, and logical correctness under concurrent interleaving.

How would you explain it like I'm…

Many things at once

In a busy kitchen, one cook stirs a pot, another chops carrots, and another washes plates, all at the same time. They have to share the sink and the stove without crashing into each other. Concurrency is just lots of things happening together and not bumping.

Many things happening together

Concurrency means a system has several things going on at the same time, and those things sometimes need to share or take turns. Think of a kitchen with three cooks all reaching for the same pan. They need rules about who goes first and how to wait so the meal still comes out right. Computers do this too: many programs share one processor and memory, and the system has to keep their actions in a sensible order.

Overlapping tasks needing coordination

Concurrency is the property of a system in which multiple independent or interdependent processes proceed in time-overlapping fashion. The processes might be threads in a program, customers at a bank, or signals in a brain. Because they overlap, you have to worry about ordering (which event happened first?), resource contention (who gets the shared printer?), and logical correctness when their steps interleave in unexpected ways. Concurrency is not the same as parallelism, which is about literally executing things simultaneously on different hardware. A system can be concurrent on a single processor by rapidly switching between tasks, and it still needs the same coordination tools.

Concurrency is the ability of a system to manage multiple independent or interdependent processes occurring simultaneously in time, raising structural questions about ordering, resource contention, and logical correctness under arbitrary interleaving. It is distinct from parallelism (true simultaneous physical execution): a single-core CPU can be highly concurrent by time-slicing, and a parallel system without coordination need not be concurrent in the design sense. The core challenge is that when separate loci of execution share state, the set of possible interleavings explodes combinatorially, so naive code that is correct in sequential isolation may exhibit race conditions, deadlocks, livelocks, or starvation when run concurrently. Coordination mechanisms — locks, semaphores, monitors, message passing, transactional memory, lock-free data structures — exist to constrain interleavings to those that preserve invariants. Reasoning frameworks include happens-before relations, linearizability, serializability, and various memory-consistency models that specify exactly what concurrent observers can see.

Structural Signature¶

Multiple simultaneous independent or interdependent processes ^[1]
Explicit or implicit synchronization and coordination mechanisms ^[2]
Shared-resource contention and conflict-avoidance structures ^[3]
Time-ordering sensitivity and causality preservation across parallel execution ^[4]
Interleaving-safe invariants and atomicity boundaries ^[5]
Speed-up potential versus coordination overhead trade-off ^[6]

What It Is Not¶

Not parallelism. Parallelism is the physical simultaneous execution of multiple processes on multiple processors; concurrency is the logical interleaving of process execution, which can occur on a single processor via time-slicing. A system can be concurrent without being parallel, or parallel without exhibiting concurrency semantics.
Not asynchrony alone. Asynchrony means operations do not block the caller; concurrency requires that multiple operations actually overlap in time. An asynchronous single-threaded event loop may appear concurrent but is not; true concurrency requires multiple active agents.
Not mere task division. Dividing a task into independent subtasks is decomposition; making those subtasks run concurrently is concurrency. The same subtask structure can be executed sequentially or concurrently.
Not atomicity. Concurrency creates atomicity problems (race conditions); atomicity itself (ensuring an operation appears indivisible) is a solution to a concurrency problem, not its defining feature.

Broad Use¶

Concurrency appears wherever multiple independent agents or processes must coexist in overlapping time:

Computing: multithreading, multiprocessing, distributed systems, event-driven I/O, concurrent transactions in databases.
Biology: parallel processing in neural circuits, simultaneous metabolic pathways, organ systems operating in tandem.
Economics: concurrent market transactions, auction bidding, financial derivatives pricing under parallel order flows.
Project management: parallel task execution across teams, workflow scheduling with resource constraints.
Infrastructure: traffic light coordination, power grid load balancing, telecommunications routing.

Clarity¶

Concurrency clarifies by forcing explicit recognition of what can happen simultaneously (independence) and what cannot (synchronization points). Vague promises like "this is fast" resolve into concrete ordering constraints or explicit locks. The clarifying force is to make coordination requirements checkable and to turn implicit temporal assumptions into explicit guards ^[7].

Manages Complexity¶

Enables decomposition: large systems can be structured as independent concurrent agents, each with simpler local logic.
Makes latency irrelevant: while one process waits for I/O, others continue. Concurrency separates the elapsed time of the entire system from the execution time of any single process.
Supports responsiveness: concurrent systems can be interrupted, context-switched, or reordered without forcing the entire system to wait on a single slow operation.
Requires explicit coordination: mutexes, semaphores, condition variables, barriers, and other synchronization primitives make coordination visible and analyzable.
Scales reasoning: as the number of concurrent agents grows, reasoning about arbitrary interleavings becomes intractable; concurrency forces architects to identify truly independent regions and narrow synchronization interfaces ^[8].

Abstract Reasoning¶

Concurrency trains a reasoner to ask:

Which operations or processes can proceed independently without affecting correctness?
Which operations must be mutually exclusive (atomic)? Which orderings of concurrent operations violate invariants?
What happens in each possible interleaving of concurrent execution? Are there some interleavings that are correct and others that are not? (If all are correct, the system is race-free or linearizable; if some are not, synchronization is needed.)
What is the cost of synchronization in terms of latency, throughput, and lock contention?
Does the system deadlock, livelock, or starve under any interleaving?

Knowledge Transfer¶

Role mappings across domains:

Concurrent process ↔ agent / actor / thread / task / workflow / organ / market participant
Synchronization ↔ mutual exclusion / barrier / handshake / negotiation / governance rule
Shared resource ↔ critical section / lock / semaphore / allocation pool / bottleneck / shared data
Race condition ↔ collision / interference / conflicting bid / scheduling clash / resource contention
Atomicity ↔ indivisible action / single decision / one-shot allocation
Deadlock ↔ stalemate / circular waiting / mutual blocking
Livelock ↔ thrashing / busy-waiting / futile negotiation

A concurrent program managing multiple network connections, a factory floor with concurrent assembly lines, and a neuron firing while others also fire are all managing the same structural problem: ensuring that independent agents can overlap in time without corrupting each other's work ^[7].

Examples¶

Formal/abstract¶

A concurrent system enforcing linearizability (Herlihy & Wing 1990) ensures that every concurrent history of operations appears to execute sequentially in some order consistent with real-time. Consider two threads, A and B, both reading and incrementing a shared counter. If the counter is unprotected, a race condition can occur: both threads read value 5, both increment to 6, and only one increment is observed (lost update). Protecting the counter with a mutex ensures that each increment is atomic, and the final value reflects all increments. The linearizable history is a total order respecting real-time: A reads, A increments, B reads, B increments, or B reads, B increments, A reads, A increments. The same formal framework applies whether the counter is in-memory, distributed across multiple servers, or mediated by a transactional database ^[5].

Mapped back: This instantiates the structural signature — multiple concurrent processes accessing a shared resource, explicit synchronization (mutex) preventing race conditions, atomicity boundaries ensuring invariants hold despite arbitrary interleaving.

Applied/industry¶

A cloud data center's request router handles millions of concurrent client connections. Each connection is a concurrent agent; shared resources include server capacity, network bandwidth, and cache slots. Without coordination, two connections might claim the same cache slot (collision), or a request might overwhelm a server (resource starvation of other clients). The router uses load balancing (synchronization via distributed decision-making) to ensure each server receives a proportional share of requests, and per-connection rate limiting (atomicity via quota checks) to prevent any single client from monopolizing resources. The correctness criterion is that no request waits indefinitely (liveness) and no two requests corrupt each other's state (safety). The coordinator's latency is a critical performance bottleneck: too strict (too much synchronization) and throughput suffers; too loose (too little coordination) and correctness fails ^[9].

Mapped back: This shows the same structural commitments (independent agents, shared resources, synchronization requirements, atomicity boundaries, liveness and safety guarantees) translate from low-level kernel synchronization to large-scale distributed systems, demonstrating concurrency's role as a universal abstraction of simultaneous execution.

Structural Tensions¶

T1: Independence vs Coordination. More independent concurrency enables better parallelism and fault isolation, but requires more explicit synchronization to ensure correctness. Over-synchronizing (pessimistic locking, global locks) serializes the system; under-synchronizing (optimistic concurrency) risks race conditions and invariant violations. A common failure is choosing the wrong synchronization granularity: locks too coarse (unnecessary blocking) or too fine (excessive synchronization overhead) ^[10].
T2: Safety vs Liveness. Safety (nothing bad happens: no race conditions, no corruption) requires synchronization and exclusion. Liveness (progress: all threads eventually finish) requires avoiding deadlock and starvation. Deadlock prevention and starvation avoidance can conflict with race condition prevention. A common failure is a system that is safe but deadlocked (all threads stuck) or live but unsafe (concurrent modifications corrupt state) ^[1].
T3: Determinism vs Nondeterminism. Concurrent systems are inherently nondeterministic: the interleaving of concurrent operations depends on timing, scheduling, and hardware behavior outside the programmer's control. Testing a concurrent program may pass all tests and still fail catastrophically in production under a different interleaving. Forcing determinism via global synchronization loses concurrency; allowing nondeterminism makes correctness fragile. A common failure is assuming the test interleaving is representative and deploying untested interleavings to production ^[4].
T4: Scalability vs Coherence. Adding more concurrent agents improves throughput up to a point (Amdahl's Law), but coherence (keeping all agents aware of shared state) becomes increasingly expensive. Distributed systems solve this by accepting eventual consistency (agents may temporarily disagree on state) at the cost of application-level complexity. Strongly consistent systems (all agents immediately see all updates) limit scalability. A common failure is designing for strong consistency without measuring the scalability cost, then being surprised by contention as load increases ^[11].
T5: Responsiveness vs Latency Predictability. Concurrent systems can preempt long-running operations and service short requests quickly (good responsiveness), but preemption adds scheduling overhead and makes latency unpredictable (bad for real-time systems). Hard real-time systems (airborne avionics, medical devices) restrict concurrency to maintain latency guarantees; soft real-time systems (video streaming, interactive UI) accept occasional latency spikes for better responsiveness. A common failure is applying soft real-time concurrency patterns to hard real-time domains.
T6: Visibility vs Performance. Making all concurrent actions visible (e.g., global event logs, synchronized clocks) ensures correctness but destroys performance (every action must wait for acknowledgment). Optimizing for performance (local buffers, asynchronous updates) loses visibility, making debugging harder and failure scenarios less predictable. A common failure is deploying high-performance concurrent systems without sufficient observability, then being unable to diagnose production race conditions.

Structural–Framed Character¶

Concurrency sits at the structural end of the structural–framed spectrum: it is a pure relational pattern, the same in any domain where it appears, and nothing about its meaning depends on a particular field's vocabulary or assumptions. It names the condition in which multiple loci of execution proceed in time-overlapping fashion, raising questions of ordering, resource contention, and correctness under interleaving.

Though it is most discussed in software, the same structure—simultaneous processes, the need for synchronization, contention over shared resources, sensitivity to time-ordering—describes traffic at an intersection, transactions against a shared ledger, or workers coordinating on a shared task just as faithfully. It carries no evaluative weight: concurrency is a configuration of activity, not a good or bad one. Its origin is formal and relational rather than institutional, it can be defined without reference to human practices, and applying it feels like recognizing a pattern of overlapping activity that is already present. On every diagnostic, it reads structural.

Substrate Independence¶

Concurrency is about as substrate-independent as a prime can be — composite 5 / 5 on the substrate-independence scale. Its structural signature — multiple simultaneous processes with synchronization, resource contention, and preserved causality — is stated entirely in process-agnostic terms and applies identically to software threads, dividing cells, interleaved organizational workflows, and physical fluid dynamics. The examples are not analogies but the same logic: lock conflicts in computing, meiotic coordination in biology, traffic management in society. With perfect marks across breadth, abstraction, and transfer, it is truly substrate-universal and one of the catalog's canonical 5s.

Composite substrate independence — 5 / 5
Domain breadth — 5 / 5
Structural abstraction — 5 / 5
Transfer evidence — 5 / 5

Relationships to Other Abstractions¶

Current abstraction Concurrency Prime

Foundational — no parent edges in the catalog.

Children (6) — more specific cases that build on this

MapReduce Domain-specific presupposes Concurrency

MapReduce presupposes concurrent independent map and reduce tasks as the execution regime its programmer contract is designed to make safe.
Consistency Model Prime presupposes Concurrency

'Concurrency is the CONDITION — multiple operations in flight; a consistency model is the CONTRACT specifying which observations of that concurrency are legal.
Coordination Prime presupposes Concurrency

Coordination presupposes concurrency because aligning independent actors into coherent collective outcome only arises when multiple processes proceed simultaneously.

▸ Show 3 more

Eventual Consistency Prime presupposes Concurrency
Concurrency raises the reconciliation question; eventual_consistency is 'one discipline for living with the divergence concurrency creates' — accept uncoordinated concurrent writes, diverge, reconcile by merge.
Interference and Contention Prime presupposes Concurrency
Interference and contention presupposes concurrency because mutual interference among shared-resource consumers requires the consumers to proceed in overlapping time.
Race Condition Prime presupposes Concurrency
Race Condition presupposes Concurrency, whose structure must already obtain for the child mechanism to be meaningful or operational.

Neighborhood in Abstraction Space¶

Concurrency sits among the more crowded primes in the catalog (10^th percentile for distinctiveness): several abstractions describe nearly the same structure, so a description that fits it will tend to fit its neighbors too — transporting it usually means disambiguating within this family rather than landing on it exactly.

Family — Trajectories, Thresholds & Path Dependence (31 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-26

Not to Be Confused With¶

Concurrency must be distinguished from Synchronization, its nearest neighbor (similarity 0.777), though the two are often conflated. Concurrency is the structural fact that multiple independent or interdependent processes can proceed in time-overlapping fashion, raising questions of ordering, resource contention, and correctness under interleaving. Synchronization is the mechanism by which the timing of oscillating or cyclic processes is aligned to maintain a desired phase relationship or coherence. Synchronization addresses questions like "how do two clock oscillators stay in phase?" or "how do two threads coordinate their accesses to a lock?" — it is about temporal alignment and phase maintenance across independent clocks or processes. Concurrency asks "what orderings of operations are safe?" and "how do we prevent corruption when multiple processes access the same resource?" Synchronization keeps oscillators in step; concurrency manages access and ordering so that overlapping processes do not corrupt each other. A network of oscillators achieving synchronized firing is a synchronization problem; a database managing concurrent transactions so that reads and writes do not race is a concurrency problem. Some concurrent systems use synchronization (e.g., network time protocol synchronizes clocks to coordinate distributed events), but the problems are distinct.

Concurrency is distinct from Transaction, which is a unit of work guaranteed to execute atomically (all-or-nothing commit) with respect to a database or system state. A transaction can be non-concurrent (single-threaded execution of a series of operations grouped into one atomic unit) or concurrent (a transaction executing alongside other transactions). The transaction's defining property is atomicity and isolation — the all-or-nothing property and the isolation from other concurrent work — not the concurrency itself. A transaction in a single-threaded database engine is still a transaction; multiple concurrent operations without transactional grouping are still concurrent but not transactional. Transactions are a solution to certain concurrency problems (ensuring isolation and atomicity across concurrent accesses), but concurrency is broader than transactions alone.

Concurrency is not Sequencing, which determines the specific total order in which tasks must execute and prerequisites must be satisfied. Sequencing answers "what is the execution order?" and "when can task B start given that task A must complete first?" Concurrency answers "what can happen simultaneously?" and "which orderings of concurrent operations preserve correctness?" Sequencing is deterministic and total (every task has a defined position in the order); concurrency is often nondeterministic and partial (some operations can proceed in any order, others are constrained). A build system that sequences: "compile source files, link object files, run tests" in that strict order is using sequencing. The same build system that allows concurrent compilation of independent source files (partial order: each can proceed whenever its dependencies are ready) is using concurrency. Concurrency can be embedded within sequencing (run concurrent operations within each sequential phase), and sequencing can be imposed on concurrent systems (force total ordering of concurrent events for determinism).

Concurrency is distinct from Coordination, which is the active apparatus — protocols, signals, rules, negotiation mechanisms — that aligns independent agents toward coherent outcomes despite concurrency. Coordination is what you do in response to concurrency; concurrency is the structural fact that multiple processes overlap. A concurrent system with poor coordination exhibits race conditions, deadlock, and corruption; a concurrent system with good coordination achieves coherent outcomes through synchronization primitives, message passing, consensus protocols, or other coordinating mechanisms. Concurrency without coordination is dangerous; coordination without concurrency is unnecessary. The two are complementary: concurrency creates the problem; coordination solves it. Describing a system as "highly concurrent and well-coordinated" means many processes overlap and their interactions are managed through explicit protocols. Describing a system as "poorly coordinated" acknowledges concurrency but highlights failure in the coordination apparatus.

Concurrency is not Deadlock, which is a failure mode in concurrent systems where circular waiting prevents any process from proceeding. Deadlock is a pathological outcome when concurrency is managed badly — a particular ordering of operations and acquisition of resources leads to mutual waiting cycles. Concurrency is the structural property that enables deadlock to occur; deadlock is the accident that occurs when concurrency is mismanaged. A system without concurrency cannot deadlock (single-threaded systems proceed sequentially; waiting on self is impossible). A system with concurrency can deadlock if processes acquire resources in an order that creates circular dependencies (A waits for resource held by B; B waits for resource held by A). Deadlock prevention, detection, and recovery are mechanisms for avoiding the deadlock failure mode within concurrent systems; they do not change the fact that concurrency occurs.

Solution Archetypes¶

Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.

Built directly on this prime (9)

Also a related prime in 12 archetypes

Assumption-Bounded Distributed Agreement: Make distributed agreement achievable by declaring the fault, timing, membership, and validity model, preserving safety when progress is uncertain, and using only decision evidence that is valid under those assumptions.
Concurrent Cross-Functional Integration: Integrate specialized perspectives in parallel through shared artifacts, live interfaces, synchronized decisions, and continuous recombination so conflicts appear while they are still cheap to resolve.
Coordination and Synchronization Across Reentry Phases: Bring separated parts back together in the right order, at the right tempo, with shared state visibility and the ability to pause when reentry creates overload or unsafe coupling.
Deadlock Prevention: Structure resource acquisition, authority, or sequencing so circular blocking cannot arise.
Deferred Fulfillment Placeholder: Create a first-class placeholder for a committed future value so dependent work can proceed, compose, wait, cancel, or fail explicitly before the value exists.
Demand-Triggered Deferred Evaluation: Represent optional or path-dependent work as a suspended unit, realize only the dependency closure demanded now, and make result sharing, side effects, failure timing, cancellation, lifetime, and first-use latency explicit.
Fault-Tolerant Distributed Consensus: Declare the fault and timing model, preserve agreement and validity with intersecting evidence, and pursue termination only under assumptions that make progress possible.
Head-of-Line Blocking Relief: Prevent one blocked or slow item at the front of a queue from delaying everything behind it.
Nested and Distributed Transaction Coordination: When one transaction spans multiple participants or nested scopes, make the transaction boundary, protocol, participant states, failure behavior, compensation path, and closure evidence explicit before letting local commits create irreversible partial outcomes.
Request–Response Capability Provisioning: Make a scarce or specialized capability addressable as a service that many independent clients can request and receive responses from under explicit capacity and failure rules.

▸ Show 2 more

Notes¶

Concurrency has been central to computer science since shared-memory multiprocessing and network protocols emerged. Edsger Dijkstra's work on mutual exclusion (1965) established foundational problems and solutions (semaphores, monitors). The CAP theorem (Brewer 2000) formalized the trade-offs in distributed concurrent systems. Modern languages and frameworks (Go, Rust, Erlang) embody different concurrency philosophies (shared-memory threads, message-passing actors, async/await). The problem remains unsolved in practice: concurrent bugs are among the most dangerous and hardest-to-find categories of software defects.

References¶

[1] Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts. 9^th ed. Hoboken, NJ: Wiley, 2013. Standard OS text; the process-synchronization and deadlock chapters cover concurrent processes, race conditions, critical sections, safety, and liveness. SUPPORTS marker 046 (multiple simultaneous independent/interdependent processes) and marker 058 (T2: safety vs liveness — deadlock/starvation vs race-condition prevention). Link is the official book site. ↩

[2] Dijkstra, E. W. "Solution of a Problem in Concurrent Programming Control". Communications of the ACM 8, no. 9 (1965): 569. Formalizes the mutual-exclusion problem and gives the first software solution using only atomic reads/writes. SUPPORTS marker 047 (explicit/implicit synchronization and coordination mechanisms). DOI verified. ↩

[3] Hoare, C. A. R. "Monitors: An Operating System Structuring Concept". Communications of the ACM 17, no. 10 (1974): 549-557. Introduces the monitor as a higher-level synchronization construct guarding shared resources (with condition variables). SUPPORTS marker 048 (shared-resource contention and conflict-avoidance structures). DOI verified. ↩

[4] Lamport, L. "Time, Clocks, and the Ordering of Events in a Distributed System". Communications of the ACM 21, no. 7 (1978): 558-565. Defines the happened-before partial order and logical clocks for ordering distributed events. SUPPORTS marker 049 (time-ordering sensitivity and causality preservation). PARTIALLY SUPPORTS marker 059 (T3: determinism vs nondeterminism) — Lamport gives the causal-ordering framework but does not directly treat testing-interleaving nondeterminism; defensible but indirect. DOI verified. See flag on 059. ↩

[5] Herlihy, M. P., & Wing, J. M. "Linearizability: A Correctness Condition for Concurrent Objects". ACM Transactions on Programming Languages and Systems 12, no. 3 (1990): 463-492. Defines linearizability: each operation appears to take effect atomically at some point between invocation and response, consistent with real-time order. SUPPORTS marker 050 (interleaving-safe invariants and atomicity boundaries) and marker 055 (the linearizable-history total order in the formal example). DOI verified. ↩

[6] Amdahl, G. M. "Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities". In Proceedings of the AFIPS Spring Joint Computer Conference, vol. 30, 483-485. AFIPS Press, 1967. Origin of Amdahl's Law: serial fraction bounds achievable speedup. SUPPORTS marker 051 (speed-up potential vs coordination overhead trade-off). DOI verified. ↩

[7] Tanenbaum, A. S., & Van Steen, M. Distributed Systems: Principles and Paradigms. 2^nd ed. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. Canonical distributed-systems text covering synchronization, coordination, consistency, and replication. SUPPORTS marker 052 (clarity: turning implicit temporal assumptions into explicit guards) and marker 054 (independent agents overlapping in time without corrupting each other's work). DOI/link is the archive.org copy. NOTE: the embedded annotation in the source ('load balancing as distributing divisible work ... distribution vs provisioning') is a mismatched carry-over from another prime's use of this text; the book nonetheless supports the general coordination/clarity claims on 052/054. ↩

[8] Coulouris, G., Dollimore, J., Kindberg, T., & Blair, G. Distributed Systems: Concepts and Design. 5^th ed. Boston: Addison-Wesley (Pearson), 2011. Standard distributed-systems text; treats decomposition into concurrent components and narrowing synchronization interfaces. SUPPORTS marker 053 (scaling reasoning: identifying truly independent regions and narrow synchronization interfaces). Link is the official book site. NOTE: the 5^th edition author list is 'Coulouris, Dollimore, Kindberg, & Blair' (Blair added; Dollimore/Kindberg order differs from the prime's 'Coulouris, Kindberg, & Dollimore'). Minor citation-fix. ↩

[9] DeCandia, G., Hastorun, D., Jampani, M., et al. (2007). "Dynamo: Amazon's highly available key-value store." In Proceedings of the 21^st ACM Symposium on Operating Systems Principles (pp. 205–220). ACM. ↩

[10] Hennessy, J. L., & Patterson, D. A. (2017). Computer Architecture: A Quantitative Approach (6^th ed.). Morgan Kaufmann. ↩

[11] Vogels, W. "Eventually Consistent". Communications of the ACM 52, no. 1 (2009): 40-44. Explains eventual consistency and the consistency/availability trade-offs of replicated distributed data. SUPPORTS marker 060 (T4: scalability vs coherence — accepting eventual consistency at the cost of application complexity). DOI verified. ↩

[12] Brewer, E. A. (2000). "Towards robust distributed systems." In Proceedings of the 19^th Annual ACM Symposium on Principles of Distributed Computing (PODC). ACM.

[13] Gustafson, J. L. (1988). "Reevaluating Amdahl's law." Communications of the ACM, 31(5), 532–533.

[14] Drucker, P. F. Management: Tasks, Responsibilities, Practices. New York: Harper & Row, 1974. A management treatise. Tier C (bibliography only) and an apparent cross-DP carry-over (with the role-conflict table) unrelated to concurrency's claims. Link is the archive.org copy. See flag on orphan/duplicate contamination.

[15] Penrose, E. T. The Theory of the Growth of the Firm. Oxford: Oxford University Press, 1959. Resource-based theory of the firm. Tier C (bibliography only); cross-DP carry-over unrelated to concurrency. Link is the archive.org copy. See flag.

[16] Dean, J., & Ghemawat, S. "MapReduce: Simplified Data Processing on Large Clusters". Communications of the ACM 51, no. 1 (2008): 107-113 (orig. OSDI '04). Parallel map/shuffle/reduce across worker clusters. Tier C (bibliography only). DOI verified.

[17] Gunther, N. J. Guerrilla Capacity Planning. Berlin: Springer, 2007. Develops the Universal Scalability Law for contention/coherency cost under load. Tier C (bibliography only). DOI verified.

[18] Awerbuch, B. "Complexity of Network Synchronization". Journal of the ACM 32, no. 4 (1985): 804-823. Introduces the 'synchronizer' for simulating synchronous networks atop asynchronous ones. Tier C (bibliography only). DOI verified.

[19] (Duplicate of decandia-2007 — the source defines this reference twice; single canonical entry given above.)