Skip to content

Partitioned Global Address Space

A programming model makes eligible data referable across locality domains while exposing each location's partition or affinity and defining local and remote access.

Version
v1 · 2026-10-17 · History
Domain-specific #
14244
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomain
Parallel Programming → Computer Science & Software Engineering
Aliases
PGAS

Core Idea

A partitioned global address space (PGAS) is a parallel-programming memory and interface model in which eligible data can be referred to across locality domains while the data's partition or affinity remains visible to the programmer. A language or library then defines the operations by which code in one domain accesses eligible data associated with another. “Global” describes the scope of the eligible reference surface; “partitioned” preserves the distinction between local and remote placement. Neither word says that every datum is remotely accessible or that a remote access costs the same as a local one.[1][2]

The model can take different forms. Chapel offers language constructs for querying a value's locale, executing a statement on a chosen locale and referring to a variable across locales. OpenSHMEM supplies a library interface in which processing elements (PEs) have local private data and remotely accessible symmetric objects, with operations that name a target PE. Both expose a global eligible data view and locality; their control flow, syntax and access rules differ.[2][1]

A locality unit such as one Chapel locale fills a role inside a PGAS system. That unit alone is not the whole PGAS model: the model also needs eligible cross-locality references and their operation contract.

Structural Signature

Sig role-phrases: locality domains; eligible shared data surface; visible partition or affinity; cross-domain access; contract-specific operation semantics.

  • Locality domains. Locales or PEs distinguish where work runs and data resides. Without more than one distinguishable location in the model, “local” and “remote” have no operational contrast, even if a particular run uses only one location.[2][1]
  • Eligible shared data surface. Some locations or objects are addressable through the cross-domain contract. OpenSHMEM distinguishes symmetric target storage from private local source storage; the latter does not become remotely accessible simply because it is in a PGAS program.[1]
  • Visible partition or affinity. A program can identify a value's locale or the target PE. If data placement is wholly opaque, the programmer lacks the locality signal that makes the space partitioned in this sense.[2][1]
  • Cross-domain access. The model must support a defined way to reach eligible data from a different locality. Chapel's remote update and OpenSHMEM's strided put realize this role by different interfaces.[2][1]
  • Operation semantics. The particular contract says what a remote read or write means and what synchronization is needed. A diagram of globally named nodes without access rules is not yet a programming model.[2][1]

These roles define a type of interface, not a mandate for any one hardware topology. In particular, Chapel's remote execution construct and OpenSHMEM's one-sided data routine are each source-specific ways of filling the cross-access role, not universal syntax for PGAS.

What It Is Not

  • Not a license to address every process's private bytes. OpenSHMEM qualifies remote targets by symmetric storage and its API rules. A private object can remain private in a program with a partitioned global address space.[1]
  • Not a particular node, locale or NUMA machine. Those may supply locality domains or physical costs. Without a programming contract joining eligible cross-domain references to visible affinity, the hardware alone is not this model.[2][1]
  • Not merely private message passing. Messages can move values between processes without exposing eligible remote data locations as a shared reference surface.
  • Not necessarily physical distributed shared memory. A PGAS contract may run over one locality or different hardware arrangements; physical replication and maintenance of a shared-data illusion are additional implementation claims. Conversely, a shared-memory implementation that hides all locality lacks the required programmer-visible partition.[2]
  • Not automatic parallel execution. The Chapel authors explicitly separate changing locale with on from creating concurrent tasks. Remote location and simultaneous work are different dimensions.[2]
  • Not always one-sided communication. OpenSHMEM's cited implementation uses one-sided puts and gets. Chapel's cited language example changes execution locale and references a remotely allocated variable; the common type is the global eligible data surface with exposed locality, not one required transfer mechanism.[2][1]

Scope of Application

PGAS applies to parallel languages and libraries that let code work with eligible data across locality domains while retaining a visible distribution or affinity. Its use is literal in Chapel's multi-locale language model and OpenSHMEM's PE-based symmetric-object API. The relevant units may be language locales or library PEs, and their implementation can use physical memory and communication mechanisms chosen by the system.[2][1]

The cited Chapel paper was written for a 2009 implementation. Its nested on example illustrates source-level cross-locale reference; it is not a guarantee about every current Chapel version or program. The OpenSHMEM 1.0 FINAL specification defines a library contract and includes a worked strided-put listing. That listing is an official example adapted from SGI material, not a reviewer-executed production incident. These different source grades support a shared model type without pretending that a worked example proves a speedup.[2][1]

The original screened “Locale (computer hardware)” member names a locality unit rather than the entire PGAS programming model. A locale may be used by one realization, but classification of the unit itself requires a separate identity decision.

Clarity

A useful first question is which data are eligible for remote reference? A global view can coexist with private storage. In OpenSHMEM's worked example, a process-local source array supplies values, while a static symmetric target on another PE receives them. Calling both arrays “shared” would erase the rule that explains why the put is valid.[1]

The second question is where does the data reside? In the Chapel example, x is allocated on Locale 1 while code on Locale 2 updates it. Lexical access to x does not move x's home in that example, and the on statement by itself does not introduce concurrency. In OpenSHMEM the target PE is named as an argument to the put routine. Both expose locality, though one uses a language-level execution construct and the other a library data operation.[2][1]

The third question is what does the operation promise? A remote write, its completion and its visibility to another PE are governed by the selected contract and synchronization. A declaration that the space is global is not a complete memory-ordering guarantee.

Manages Complexity

The model lets a programmer speak about eligible distributed data without manually turning every cross-location use into an unrelated private-message protocol. At the same time, affinity prevents that simplified view from hiding all placement information. Chapel's distributions can connect an array's logical shape to data placement, while OpenSHMEM exposes target PEs in its operations. The abstraction compresses naming and access, yet keeps locality available when placement matters.[2][1]

This compression has a limit. A compact source expression can still entail remote communication, and source-level addressability does not ensure low latency, parallel progress or a valid synchronization order. The cited Chapel authors discuss local-placement optimizations for distributed arrays; those are implementation-specific ways to exploit affinity, not a promised property of every PGAS access.[2]

Abstract Reasoning

To classify a proposed system, first locate its eligible data surface. Identify the objects or locations that may be referenced from another domain and separate them from private state. Then identify the visible partition: a locale query, PE argument, distribution or similar source-level device. Finally, find the operation contract that connects a cross-domain reference to a defined effect. If one of these roles is absent, “globally distributed memory” may be a physical description or analogy rather than this programming model.[2][1]

To reason about one access, trace origin → target affinity → eligible object → operation → synchronization point. In Chapel's nested on example, executing on Locale 2 while x remains on Locale 1 makes the cross-locale reference visible. In the OpenSHMEM strided-put example, PE 0 supplies five selected local values, PE 1 owns the eligible symmetric target, and a barrier precedes the shown observation. A comment inside that listing says “ten words,” but the call arguments and specified routine select five elements; the code and API semantics determine this readout.[2][1]

This trace identifies communication and legality questions before making performance claims. It also prevents an “any task can touch any datum” inference from an example that actually has eligibility restrictions.

Knowledge Transfer

The Chapel and OpenSHMEM cases preserve the same role relationship across different programming interfaces: a shared eligible location surface is distributed among named localities, and code can reach eligible remote data while seeing where that data belongs. Chapel couples lexical reference to an on execution context; OpenSHMEM names a PE in a library call. Their shared PGAS structure is literal, not a metaphor borrowed from one API.[2][1]

That transfer does not require copying Chapel's task migration into OpenSHMEM or OpenSHMEM's one-sided call syntax into Chapel. It also does not transfer an identical consistency rule or cost model. Each new language or library must demonstrate its own eligible-object rule, locality surface and operation semantics.

Examples

Canonical: Chapel nested on update

Deitz and colleagues show code that declares x on Locale 1 and then executes a statement on Locale 2 that updates x. They explicitly describe x as stored on Locale 1, even though the remote statement refers to it. Their discussion then distinguishes this locality change from task parallelism; on alone does not create a concurrent task.[2]

Mapped back: locality domains = Locales 1 and 2; eligible shared surface = lexically referable x; visible affinity = x's allocation locale and the on target; cross-domain access = update of x from code on Locale 2; operation semantics = Chapel's on and variable-reference behavior in the reported implementation.

This is a worked language example. It establishes the role map; it is not a reviewer-run benchmark or evidence that every value in a program is remotely accessible.

Applied / In Practice: OpenSHMEM strided put

OpenSHMEM 1.0 FINAL Listing 6 gives a two-PE program with a private source array and static symmetric target. On PE 0, shmem_short_iput selects five alternate elements from the local source and writes them into the PE 1 target. Barriers surround the output check. The listing's “ten words” in-code comment conflicts with the call's count argument of five and the surrounding explanation; five is the supported reading.[1]

Mapped back: locality domains = PE 0 and PE 1; eligible shared surface = symmetric target; visible affinity = destination PE argument and per-PE target copy; cross-domain access = strided put into PE 1 storage; operation semantics = the specified routine parameters and barriers.

The example has a different control surface from Chapel's language-level remote execution. It remains an official worked API example, not independent observation of a deployed application.

Structural Tensions

T1: Global referability vs. locality cost. A global eligible view makes distributed data easier to name and use, while remote access may require communication. Leaning toward seamless cross-locality references reduces source-level handling but can conceal that cost. Leaning toward explicit placement and local work exposes more program structure and asks the programmer or compiler to manage affinity, while it may avoid unnecessary remote transfer. Neither choice guarantees higher performance.[2][1]

Diagnostic: Which eligible accesses cross a locality boundary, and would a different placement of work or data change that path?

Structural–Framed Character

Structural or framed? PGAS is structural within parallel programming: eligible remote references, named locality domains, and access semantics can be identified and tested in a language or library specification. Its memory-interface relation is not conferred simply by calling a system “global.”[2][1]

Evaluative weight. PGAS names a programming model, not a promise of speed, fairness, or ease of use. Its remote accesses can still cost communication. A standards body's publication establishes the rules of a particular interface; it does not make an implementation efficient merely by naming the model.[2][1]

Human practice and institutional origin. Language and library designers choose the eligible-object rule, locality surface, and operation semantics; programmers choose placements and synchronization. The cited Chapel paper and OpenSHMEM specification are concrete products of parallel-programming practice. Once a contract is fixed, whether a particular access is eligible and remote follows from that contract and the code, rather than a reader's metaphor.[2][1]

Vocabulary travel and import versus recognition. “Global,” “partition,” and “locale” can describe organizations or networks. To recognize PGAS across implementations, find an eligible cross-locality data-reference surface, visible affinity, and a defined programming access contract. A social organization's “global but partitioned” information flow is an analogy unless it supplies that memory-interface relation.

Portable skeleton and Prime scope. Interface names a broader rule-governed exchange surface, and the PGAS access contract exhibits part of that structure. The bare idea of locations linked by references is thinner than Interface's full bounded-exchange signature and does not by itself establish a separate Prime. The Chapel and OpenSHMEM cases are both programming settings; they do not demonstrate that the complete PGAS configuration transfers outside this domain.

Its character: a domain-specific structural programming model whose eligible data, locality signal, and access rules are fixed by a particular language or library contract.

Structural Core vs. Domain Accent

The portable comparison skeleton is referable objects in distinguishable locations plus rules for crossing a location boundary. Interface captures the rule-governed exchange aspect, but its full signature is broader and different from the bare location/reference skeleton. Whether that thinner skeleton warrants a distinct Prime requires evidence from non-programming settings; a network directory or remote service endpoint resembles only some PGAS roles and supplies no such proof here.

The domain-bound mechanism is constitutive: the locations are programming localities, eligible data locations are accessible under a language or library memory model, partition or affinity is visible, and local and remote operations have specified effects. Address Space supplies a related naming surface, while Parallel Computing concerns concurrent computation rather than the necessary memory-interface differentia. The complete configuration in the two cited cases remains a domain-specific programming model.

This entry is part of Interface.

The Interface Prime helps describe the declared operations through which a programmer reaches eligible data. It does not by itself specify a shared data surface or visible locality. Parallel Computing is an adjacent domain-specific activity: PGAS systems can support it, but the Chapel authors' on example shows that changing locality alone does not create simultaneous execution.[2]

Distributed Shared Memory is a close neighbor, but its live identity requires physically separate active memories maintained as a shared-data view. PGAS is a programming contract whose role relation does not by itself certify that physical mechanism. Similar words should not be turned into a taxonomic edge without that full condition.

Relationships to Other Abstractions

Local relationship map for Partitioned Global Address SpaceParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Partitioned GlobalAddress SpaceDOMAINPrime abstraction: Interface — is part ofInterfacePRIME

Current abstraction Partitioned Global Address Space Domain-specific

Parents (1) — more general patterns this builds on

  • Partitioned Global Address Space is part of Interface Prime

    Every PGAS programming model contains a bounded access interface that declares eligible remote data, visible locality, operations, and their effects.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Partitioned Global Address Space sits in a moderately populated region (57th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Network Security Vulnerabilities & Trust (30 abstractions)

Nearest neighbors

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

Not to Be Confused With

  • A locale or PE: a locality unit fills one role; it is not the complete cross-locality eligible-data model.
  • NUMA hardware: access-cost topology alone is not a language or library contract.
  • Private message passing: data transfer without globally referable eligible locations does not meet the shared-surface test.
  • Uniform shared-memory abstraction: hiding all placement loses the exposed partition that distinguishes this model.
  • One-sided communication: a common implementation style in OpenSHMEM, not the defining operation of every PGAS language or library.[1]
  • Task parallelism: remote execution context and concurrent task creation are separately specified in the Chapel source.[2]

References

[1] OpenSHMEM (project authors and collaborators), OpenSHMEM Application Programming Interface Version 1.0 FINAL, 2012. Consulted §§2.1–2.2 PGAS and SHMEM, printed pp. 6–7; §§5–6 memory/execution; §8.8 strided puts; Appendix E.1 Listing 6, printed p. 108 / zero-based PDF p. 107. The listing is adapted from SGI man pages and was not reviewer-executed. 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] Steven J. Deitz, Bradford L. Chamberlain, Samuel Figueroa, and David Iten, “HPCC STREAM and RA in Chapel: Performance and Potential,” CUG 2009 Proceedings, HPCC STREAM and RA in Chapel: Performance and Potential. Consulted §2.1.2 locale query; §2.2 nested on x, PDF pp. 2–3; §2.3 distinction from task parallelism, PDF p. 3; §§3–4 locality/distribution implementation, PDF pp. 3–7. This is original author design and worked code, not reviewer-executed application evidence. 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 ↩y