One-Sided Communication

An origin specifies access to eligible memory associated with another participant, without a matching application receive for each transfer, under explicit access and completion rules.

Version

v1 · 2026-10-17 · History

Domain-specific #

14235

Domain group

Applied Sciences & Engineering

Origin domain

Computer Science & Software Engineering

Subdomain

Remote Memory Access → Computer Science & Software Engineering

Aliases

Remote Memory Access, RMA

Core Idea

One-sided communication lets an origin specify a supported read, write, or atomic update to eligible memory associated with another execution participant. The origin supplies the target and location information without a matching application send/receive pair for each transfer. The chosen contract separately determines legal access, ordering, completion, and visibility. “One-sided” describes the responsibility for specifying the access; it does not promise that the target never participates in synchronization or that no internal messages are exchanged.^[1][2]

The distinction is between requesting a memory effect and justifying its observation. Identifying where data should go does not establish when another participant may use it. An exposed MPI window, an OpenSHMEM symmetric object, and a registered FaRM region realize the target role differently. Their shared organization permits comparison without treating their particular consistency rules as interchangeable.^[1][2][3]

Structural Signature

Sig role-phrases:

• Origin with transfer description. One participant specifies the operation and its transfer arguments. If a matching application receiver instead chooses the destination for each payload, the central responsibility has changed.^[1]
• Eligible target memory. The contract makes a region or object accessible in another participant's context. A convenient address does not by itself establish permission, lifetime, or exposure; an unexposed private object cannot fill this role.^[1][2]
• Target and location resolution. The request identifies both the participant or region and the location within it. Naming a service alone does not identify the memory effect.^[1][3]
• Supported memory-access effect. The requested result is a defined read, write, or supported atomic operation. A family need not offer every operation. Arbitrary remote procedure execution has a different whole identity.^[1]
• Access and observation contract. Rules establish when access is permitted and what completion or synchronization warrants. Application consistency may require additional checks; a successful printout is evidence about one execution, not the contract itself.^[1][3]

These roles are necessary to the bounded mechanism. Hardware offload, a particular address representation, and a particular validation algorithm are realizations, rather than additional universal roles.

What It Is Not

Not synonymous with hardware RDMA or an idle target CPU. MPI permits several implementation strategies, while OpenSHMEM permits software progress or offload. Active-target synchronization is compatible with origin-described access. The absence of a matching application receive does not erase implementation protocols.^[1][2]

Not automatic consistency. Origin completion, target completion, and visibility to local loads are different questions. In MPI, flush_local, flush, and sync have different meanings; sync does not complete pending RMA operations. In the cited OpenSHMEM edition, fence's ordering rule is distinct from quiet's prior-put completion/visibility rule.^[1][2]

Not an entire library or programming model. SHMEM/OpenSHMEM includes collectives and synchronization as well as one-sided data operations. Those broader library features do not become synonyms for this access mechanism.^[2]

An invalid target or premature read is a failed use, not proof that the advertised interface lacks one-sided operations. Conversely, a legally supported self-target call does not alone demonstrate the cross-participant pattern considered here. The definition does not declare such API calls illegal.

Scope of Application

• Iterative parallel array exchange. MPI's formal neighbor-update example uses origin-directed puts into exposed windows and fence-delimited phases. It supplies an official programming pattern, not a witnessed scientific simulation.^[1]
• Distributed key lookup. FaRM's implemented lookup accesses remote bucket objects through its direct-read path, with a separate validity check before accepting results.^[3]
• Strided array redistribution. OpenSHMEM's official two-PE listing selects source elements for a symmetric target and uses barriers around observation and exit.^[2]

The entry concerns these computing contracts. Ordinary unilateral speech or a person acting without consultation does not acquire the memory-target roles merely because it is called “one-sided.” No universal speed advantage, absence of races, or fixed number of network operations follows.

Clarity

The name resolves who describes the access, rather than counting how many participants do work. A target can expose storage or enter a synchronization phase without receiving a matching application payload for every transfer. Similarly, “remote” identifies another participant's storage context here; it does not require a particular physical distance or network transport.^[1]

A precise account therefore names three separate events: issuing the operation, establishing the required completion condition, and accepting the data as usable. Conflating these events can turn a correct description of data movement into an unjustified claim about what another participant observes.

Manages Complexity

The mechanism compresses many API details into five questions: who issues, what storage is eligible, how it is located, what effect is requested, and what warrants observation? Strides, rank/displacement pairs, and region capabilities can be compared by the jobs they perform without pretending that their representations are identical.

This compression also localizes a failure. A wrong target is an eligibility or resolution problem. A value accepted too early is an ordering, completion, or validation problem. Calling both “a communication failure” obscures the condition that needs repair. The smaller description preserves precisely the distinctions needed to diagnose the access.

Abstract Reasoning

1. Locate responsibility. Determine whether the origin describes the target access or whether a matching application receive is needed for each transfer.
2. Check eligibility before interpreting an address. Establish the target object, exposure rule, and relevant lifetime. A locator without a valid target cannot justify access.
3. Trace the requested effect. Distinguish moving data at a named memory location from dispatching an application procedure.
4. Demand the observation warrant. Identify the source-specific epoch, completion call, barrier, or validity check. Do not substitute a similarly named routine from another contract.
5. Separate layers. An internal one-sided memory write can support a higher-level messaging service. Its presence does not make that whole service receiver-free.
6. Test the countermodel. Replace the direct memory operation with a matching payload exchange while keeping the final data unchanged. If responsibility for locating and accepting the data changes, the mechanism has changed even though the output matches.

Knowledge Transfer

The useful transfer between array exchange and key lookup is the question what permits this participant to accept this value now? In the first case, the answer follows a phase-based synchronization contract; in the second, it includes object validation. Learning that distinction prevents the transfer mechanism's name from being mistaken for a consistency proof.^[1][3]

What transfers literally is the role analysis, not a copied completion recipe. A programmer moving between these settings must recover the new eligibility and observation rules. Beyond computing, the more general idea of a bounded interface may recur, but calling a social exchange “remote memory access” would replace the defining mechanism with analogy.

Examples

Canonical

MPI iterative neighbor-array exchange. Example 12.15 of MPI-4.1 has each process update an array and issue MPI_Put operations to neighbors within opening and closing MPI_Win_fence calls. The surrounding window and epoch requirements remain part of the example's validity. This is a generic code fragment with omitted application detail, not an independently executed deployment. The separate Get/overlap example is Example 12.16 and supplies no additional call or condition to this Put case.^[1]

Mapped back: R1 is the issuing process with its transfer arguments; R2 is the neighbor's array in an initialized window; R3 is target rank plus displacement; R4 is the put; R5 is the fence-delimited access and completion contract. Replacing the put with a payload requiring a matching application receive changes the access responsibility, even if the resulting array values agree.

Applied/practice

FaRM sharded key-value lookup. The implementation reads candidate remote hash buckets and follows overflow objects when needed. Its remote-object addressing uses region capabilities and offsets. The direct-read path avoids remote CPU involvement for that read, but its result is not accepted solely because bytes arrived: runtime lock/cache-line version checks can lead to retry, and the application separately checks object incarnation against the expected fat-pointer incarnation. These are bounded implementation claims, not guarantees of every one-sided operation.^[3]

Mapped back: R1 is the lookup thread; R2 is the registered remote bucket region; R3 is the resolved capability and object location; R4 is the direct read, repeated for overflow when necessary; R5 is the implementation's validity contract and checks. A raw NIC copy without those checks does not inherit the consistent-object read guarantee. The paper reports an implementation and evaluation; it does not establish production use or evaluated failure recovery.^[3]

Original-library instance: OpenSHMEM strided put. Appendix E Listing 6 puts five strided elements from PE0's private source into PE1's static symmetric target. Its call uses target stride 1, source stride 2, and count 5; the “ten words” comment does not change that count. The listing calls shmem_barrier_all twice. Its case-specific closure is the barrier contract, not fence or quiet calls absent from this listing.^[2]

Mapped back: R1 PE0; R2 PE1's symmetric object; R3 target reference plus PE1; R4 strided short put; R5 the barriers governing observation and exit. This official worked listing corroborates a one-sided operation inside the library; it does not identify the whole library with that operation.

Structural Tensions

T1: Independent access scheduling vs. justified observation. Avoiding a matching application transfer gives the origin greater responsibility for arranging access. Concurrent use still requires a reason to accept the observed value. Stronger phase boundaries can constrain scheduling freedom; validation may require additional checks or retries. Relaxing those constraints shifts the burden to nonconflict and visibility reasoning rather than eliminating it. The cost is case-dependent, and no numerical slowdown or universal optimum is implied.

The two pressures are coupled where a program wants independent access while other activity can change the meaning of the bytes it observes. Maximizing scheduling freedom without an observation warrant can invalidate the result; maximizing assurance through indiscriminate waiting can discard useful independence. A workload without that conflict need not exhibit the same trade-off.

Diagnostic: What event or check makes this value usable now, and which scheduling freedom or validation work supplies that assurance?

Structural–Framed Character

One-sided communication is structural within distributed and parallel computing, with its admissible uses framed by a particular access contract. The origin-target arrangement can be recognized across unlike interfaces, while valid targets and completion meanings depend on the chosen edition and implementation.

Evaluative weight: “one-sided” is descriptive, not an award for speed, safety, or good design. A slow valid operation remains an instance. Human-practice dependence: programmers choose exposure and synchronization, but those choices do not make any arbitrary observation correct; the specified operational conditions constrain the result. Institutional origin: standards bodies stabilize particular contracts, yet no single institution or vendor defines all the cases.

Vocabulary travel: origin, eligible memory, location, and completion retain literal computational meanings across the examples. Their replacement by people, intentions, or promises would change the mechanism. Import versus recognition: an unfamiliar implementation qualifies through the same access responsibilities and tests, not because an observer imports the label “one-sided.” The portable contractual-exchange skeleton is related to Interface; it does not grant the full memory mechanism cross-domain reach.

Its character: a domain-specific structural memory-access mechanism whose valid uses require an explicit eligibility and ordering/completion contract.

Structural Core vs. Domain Accent

Skeletal relation. The access contract contains an operative Boundary: it distinguishes eligible target storage and permitted crossings from arbitrary locations or effects. The demarcation is a constituent of the larger access mechanism. It need not be a physical protection device, an immutable region, or a universal security guarantee.

Domain-bound mechanism. Execution participants, addressable storage, supported memory effects, and completion/visibility semantics determine the named identity. Removing them leaves a generic contractual exchange, not one-sided communication. That loss of defining content is why the whole does not clear the Prime bar.

Admissible accents. Symmetric objects, windows, and capabilities realize eligibility differently. Array strides and hash buckets change the data organization. Software progress and hardware offload change implementation. Those choices can vary while the five-role mechanism remains; their particular guarantees cannot be exchanged without checking the relevant contract.

Instantiates / Related Primes

This entry is part of Boundary.

Boundary is an internal constituent: the target domain has a stipulated eligibility rule, selective access, an exchange-regulating function, and an asymmetry between valid targets and storage outside the contract. Removing that demarcation leaves an arbitrary address without the claimed access warrant. Boundary can exist without remote-memory access; one-sided communication adds an origin, location resolution, a supported effect, and completion rules.

Interface remains a related comparison for exposed capability, hidden machinery, and responsibilities. Those similarities alone do not establish that every one-sided access mechanism carries a versioning or backward-compatibility regime. The narrower eligibility-boundary relation does not imply those additional interface features.

The neighboring programming models answer different questions. PGAS concerns global data access with locality; DSM concerns a maintained shared-memory view; RPC concerns a callable service. One-sided communication isolates who describes a memory access and what warrants its effect. An access can occur inside a larger programming model without specifying that whole model.

Relationships to Other Abstractions

Current abstraction One-Sided Communication Domain-specific

Parents (1) — more general patterns this builds on

• One-Sided Communication is part of Boundary Prime

  One-Sided Communication contains an operative boundary defining eligible target storage and the memory effects permitted across it.

Hierarchy path (1) — routes to 1 parentless root

• One-Sided Communication → Boundary

Neighborhood in Abstraction Space

One-Sided Communication sits in a moderately populated region (42^nd percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Network Security Vulnerabilities & Trust (30 abstractions)

Nearest neighbors

• Data Migration — 0.87
• Peer-to-Peer Architecture — 0.87
• Secure Channel — 0.87
• Partitioned Global Address Space — 0.87
• Geotargeting — 0.86

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

Not to Be Confused With

• Partitioned Global Address Space. A programming model organizes global access and locality. Test: does the claim specify that overall data model, or one origin-described memory operation?
• Distributed Shared Memory. A shared-memory view is maintained across physically distributed memories. Test: is the whole shared view required, or only an explicitly eligible target region?
• Remote Procedure Call. The caller names a procedure for remote dispatch. Test: is the requested effect a memory access at a located object, or execution of an application service?
• Inter-process Communication. This broader family includes mechanisms beyond remote-memory access. Test: does the positive case fill all five memory-access roles, or merely exchange information?
• Hardware RDMA. A transport facility can implement one-sided access and can also underlie messaging. Test: what contract does the application use at the layer being classified?
• SHMEM/OpenSHMEM. The library family contains one-sided routines alongside other facilities. Test: is the statement about a particular memory operation or about the library's entire identity?

References

[1] MPI Forum (2023). MPI: A Message-Passing Interface Standard, Version 4.1. §§12.1–12.2.1 printed pp.547–548 onward / PDF zero-based588–589 onward; §12.5 pp.588–589 / indices629–630; §12.5.4 pp.601–603 / indices642–644; §12.7 visibility rules pp.606–608 / indices647–649; §12.8 Example12.15 pp.618–619 / indices659–660, distinct Example12.16 p.619 / index660. Official standard and formal examples; no execution or deployment is claimed. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m

[2] OpenSHMEM (2012). OpenSHMEM Application Programming Interface, Version 1.0 FINAL. §§2.2, 5, 6.1; §8.8 printed pp.34–36 / PDF zero-based33–35; §8.15.1 pp.54–55 / indices53–54; §§8.15.3–4 pp.57–59 / indices56–58; Appendix E Listing6 p.108 / index107. Official original specification and worked listing; the cover edition is 1.0 FINAL despite the search caption “Draft.” Later API editions are not imported. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h

[3] Dragojević, A., Narayanan, D., Hodson, O., and Castro, M. (2014). “FaRM: Fast Remote Memory.” 11^th USENIX Symposium on Networked Systems Design and Implementation, pp.401–414. §2 p.402 / PDF zero-based2; §3.3 pp.405–406 / indices5–6; §3.5 p.407 / index7; §3.6 p.408 / index8; §§3.1–3.2 pp.402–405 / indices2–5; §§4.1–4.2 pp.409–410 / indices9–10. Original reported implementation; direct-read CPU and consistency claims are path-specific. Failure recovery was not evaluated. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g