Distributed shared memory¶

A shared-data programming view maintained across physically separate computer memories by a distributed implementation.

Version: v1 · 2026-10-17 · History
Domain-specific #: 14127
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomains: Distributed Systems, Parallel Programming → Computer Science & Software Engineering
Aliases: DSM

Core Idea¶

Distributed shared memory (DSM) is a way for processes on computers with physically separate memories to work through a logical shared-data view. The processes access data through a declared interface while communication and a distributed implementation maintain that interface's access and visibility rules. The memory remains physically distributed; what is shared is the programming view and the coordinated state it presents.^[1]

That view need not be one flat address space. In the systems directly compared by Levelt and colleagues, shared virtual memory (SVM) offers page-based access through a common virtual address space, whereas Orca offers typed shared data objects accessed through defined operations. Both count as DSM in the original comparison, despite unlike access units, protection boundaries, and update mechanisms.^[1] Orca's separate implementation description confirms that processes on different machines can share objects and that one runtime maintains local replicas through ordered write broadcasts.^[2]

Structural Signature¶

Distributed carrier: processors or machines with physically separate memories. Their private physical storage makes remote coordination necessary; a single physically shared memory is a different substrate.^[1]
Shared-data interface: cooperating processes can address logically common data, by loads and stores in SVM or by operations on shared objects in Orca. The interface must specify what can be accessed; a mere collection of remote stores does not suffice.^[1]^[2]
Cross-node maintenance: communication and runtime or system machinery propagate or coordinate operations so the declared shared view has defined visibility. The exact unit and protocol vary: the studied SVM coordinates pages; the cited Orca implementation replicates objects and orders write broadcasts.^[1]^[2]
Recognition test: identify the physical memory layout, the programmer-visible shared-data operations, and the visibility/coherence contract those operations receive. If any one is unspecified, calling the system DSM is premature.
Boundary: neither page faults, one global flat address space, broadcast updates, nor one universal consistency model is required by both admitted paradigms.^[1]^[2]

What It Is Not¶

DSM is not physical shared memory merely stretched over a network. The original comparison starts from multicomputers whose processors have private memories and implements a shared-data view by communication. A multiprocessor with a directly accessible physical shared memory already has a different carrier, even if its users also coordinate concurrent access.^[1]

It is not a synonym for shared virtual memory. SVM is one DSM paradigm: it supplies a flat address space divided into pages. Orca's shared objects are scoped and accessed through typed operations instead, so a flat address space or page fault cannot define DSM as a whole.^[1]^[2]

It is not simply message passing or a distributed data store. The former exposes communication as explicit transfers among private states; the latter can offer storage and retrieval without the shared-memory programming interface. A DSM implementation may use messages internally, but its programmer-visible operations are on logical shared data.^[1]

Scope of Application¶

The term applies to distributed parallel-programming systems that present shared data despite separate physical memories. To use it precisely, state the programmer-visible access unit and its operation semantics, then describe how remote updates become visible. Different DSM systems can choose different consistency, placement, replication, or synchronization rules; those choices are not silently inherited from a familiar example.^[1]^[2]

The two inspected paradigms establish this scope. In SVM, the system divides a common virtual address space into pages that may be placed or replicated across processors; the paper's studied SVM provides coherent reads and writes to addresses. In Orca, processes on different machines share abstract-data-type objects and use indivisible operations; its cited runtime can keep local replicas and broadcast writes in a common order.^[1]^[2] These are examples of particular contracts, not a proof that every DSM is sequentially consistent or uses broadcast.

Clarity¶

Keep physical distribution, logical sharing, and visibility semantics separate. Physical distribution says where bytes reside. Logical sharing says what common data processes are allowed to access. Visibility semantics say what result an operation can observe after other processes act. A page-based interface and an object-based interface can both implement these roles without sharing an address-space shape.^[1]

The unit of sharing matters. In the compared SVM it is a system-defined page; unrelated variables on one page can contend. In Orca it is a programmer-defined shared object, and only that object's declared operations are available. Calling both “shared memory” should not erase this design difference.^[1]

Manages Complexity¶

DSM lets programmers reason about common data without writing every interprocessor message themselves. That simplification creates a second design problem: the runtime must coordinate remote access, updates, and visibility. A useful comparison therefore names both the simple programming surface and the hidden distributed work needed to sustain it.^[1]^[2]

The page/object contrast illustrates why one implementation detail cannot stand for the whole concept. Page placement and false sharing matter in the studied SVM; object scope and operation granularity matter in Orca. The comparison organizes those differences under a common shared-data question while keeping their costs and guarantees explicit.^[1]

Abstract Reasoning¶

For a proposed DSM system, ask three questions in order. First, are participating processes running over separate physical memories? Second, does the programming model let them operate on logically common data instead of only sending explicit copies? Third, what rule makes the effects of those operations visible across nodes? A “yes” to the first question alone identifies a distributed system, not distributed shared memory.^[1]

Then vary one role at a time. Replacing pages with typed objects preserves the broad DSM identity if shared-data operations and their cross-node visibility remain. Removing the logical shared-data interface yields explicit messaging or remote storage. Removing the declared visibility rule leaves no determinate shared-memory semantics. This is a classification test, not a performance ranking.

Knowledge Transfer¶

The transferable lesson within distributed computing is to separate an interface's shared-data promise from the mechanism that maintains it. A programmer can see common addresses in SVM or common typed objects in Orca; the implementation may move pages, replicate objects, or coordinate writes differently. Each transfer of a design claim must say which interface and contract survive the change.^[1]^[2]

The phrase is domain-specific. Calling a social or organizational process “shared memory” would be metaphor unless it actually supplies computer processes, memory operations, and defined cross-node visibility. The two original mechanisms do not establish a substrate-independent Prime.

Examples¶

Shared virtual memory¶

Levelt and colleagues describe processes on loosely coupled processors using one shared virtual address space. The space is divided into pages distributed across processors; access rights and page replication support the studied coherent read/write interface. The carrier is physically separate memory, the shared-data interface is a virtual address space with loads and stores, and the maintenance rule coordinates page-level access. Page granularity and possible false sharing are properties of this case, not of every DSM.^[1]

Orca shared data objects¶

In Orca, processes may run on different machines yet share an abstract-data-type object. They interact through that object's programmer-defined operations, which the language makes indivisible. In the cited implementation, local replicas serve reads and reliably ordered broadcasts apply writes at nodes holding copies. The carrier remains physically separate memory, the shared-data interface is the typed object, and the maintenance rule is the implementation's object replication and ordered update. This case retains DSM without arbitrary flat-address access.^[1]^[2]

Structural Tensions¶

Ease of shared-data programming versus remote coordination cost. The shared interface hides message exchange from application code, while physical distribution still demands communication and maintenance. In the studied SVM, page layout can create contention; in Orca, object granularity and broadcasts set different costs. Diagnostic: Which operations look local to the programmer, and what remote work realizes each one?^[1]^[2]

Structural–Framed Character¶

DSM is mixed, leaning framed. Its three-role relation—physically separate memories, a logical shared-data interface, and distributed maintenance of declared operation semantics—is structural enough to recognize in the unlike SVM and Orca paradigms. But every recognition test still uses computer memories, processes, and programming operations. The term makes no normative judgment that shared memory is better than explicit messaging: the original comparison evaluates particular designs and performance, while the category itself is a technical description.^[1]

The abstraction depends on human-made programming and runtime practice. Without designed access interfaces and visibility guarantees there may be data on several machines, but no DSM programming model to identify. Its institutional origin is distributed-systems research and engineering, not an observer-independent natural kind. Its vocabulary travels readily among different architectures and languages because pages are not mandatory, yet “memory,” “operations,” and “coherence” remain pinned to computational substrates. When another computing system has the same three roles, recognizing DSM is literal transfer. Calling a social group or archive a “distributed shared memory” imports an analogy unless those roles can be instantiated as actual computer operations.

The portable skeleton is the bounded, rule-governed exchange surface that lets a user rely on a contract while hidden machinery varies. The existing Interface Prime captures that cross-domain pattern and is a strict internal constituent of DSM. The named DSM entry does not itself gain cross-domain reach from that constituent. Its character: a reusable distributed-computing structure whose access and visibility tests keep the named abstraction domain-framed.

Structural Core vs. Domain Accent¶

The skeletal relation is the Interface Prime's bounded, rule-governed exchange: an application uses a declared shared-data surface while hidden implementation details may vary. In DSM the carriers are physically separate computer memories, and a remote mechanism must maintain the operation-visibility contract. Page-based address translation, typed abstract data objects, particular replication policies, and broadcast are implementation accents. Their difference is the evidence for the broad DSM identity, because the original study explicitly recognizes both paradigms.^[1]^[2]

The domain accent is indispensable. Without memory-holding processors, shared-data operations, and a defined distributed visibility mechanism, the name loses its diagnostic meaning. Those requirements keep the named entry from clearing the Prime bar. Cross-domain reach belongs to its Interface constituent, while the DSM whole remains specific to distributed computing.

This entry is part of Interface.

DSM contains a strict Interface constituent: every admitted implementation presents a bounded, rule-governed shared-data operation surface to its applications while hiding distributed maintenance. This child-to-Interface composition/part_of edge records the internal role, not a claim that DSM is merely a kind of Interface. Interface's Boundary ancestor is satisfied by the same exposed-versus-hidden demarcation.

DSM is related to Concurrency because processes can access shared data while running in parallel, but its full live signature requires actual time overlap and contention, which are not necessary for the model to remain defined. Shared Memory is the closest domain-specific neighbor; its live common-location and region commitments do not cover Orca's typed-object interface. Neither receives a strict edge.^[1]^[2]

Relationships to Other Abstractions¶

Current abstraction Distributed shared memory Domain-specific

Parents (1) — more general patterns this builds on

Distributed shared memory is part of Interface Prime

Every DSM programming model contains a bounded shared-data access interface that hides its distributed implementation behind declared operation and visibility rules.

Hierarchy path (1) — routes to 1 parentless root

Distributed shared memory → Interface → Boundary

Neighborhood in Abstraction Space¶

Distributed shared memory sits in a sparse region of the domain-specific corpus (87^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Concurrency & Parallel Computation (35 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-17

Not to Be Confused With¶

Shared memory: a broader programming resource that can be physically local; DSM specifies separate physical memories and remote maintenance of the logical view.
Shared virtual memory: a flat, page-based kind of DSM; Orca demonstrates that typed shared objects also qualify.^[1]
Non-uniform memory access: a locality and latency property of a memory architecture, not the defining shared-data interface and remote visibility contract.
Orca fault tolerance: Kaashoek and colleagues describe checkpoint and rollback machinery in the same original paper, but that feature is not required for Orca to provide DSM.^[2]

References¶

[1] Willem G. Levelt, M. Frans Kaashoek, Henri E. Bal, and Andrew S. Tanenbaum, “A Comparison of Two Paradigms for Distributed Shared Memory,” Software: Practice and Experience 22, no. 11 (1992): 985–1010, doi:10.1002/spe.4380221105. Abstract and sections 1–2, author-hosted PDF pp. 1–4. https://www.cs.vu.nl/~ast/Publications/Papers/spe-1992.pdf registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x

[2] M. Frans Kaashoek, Raymond Michiels, Henri E. Bal, and Andrew S. Tanenbaum, “Transparent Fault-Tolerance in Parallel Orca Programs,” Proceedings of the Symposium on Experiences with Distributed and Multiprocessor Systems III (1992), 297–312. Sections 2.1–2.2, author-hosted PDF pp. 3–4. The paper's fault-tolerance design is not treated as part of the DSM identity. https://www.cs.vu.nl/~ast/Publications/Papers/sedms-1992.pdf registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n