ipc_shared_ptr: A Publish/Subscribe-Aware Smart Pointer for Cross-Process Object Lifetime Management Takahiro Ishikawa-Aso†‡ , Atsushi Yano∗‡ , Koichi Imai‡ , Takuya Azumi∗ , Shinpei Kato†
arXiv:2605.04226v1 [cs.OS] 5 May 2026
†
The University of Tokyo, Japan
∗
Saitama University, Japan
Abstract—True zero-copy Inter-Process Communication (IPC) in publish/subscribe (pub/sub) middleware such as Robot Operating System 2 (ROS 2) requires subscribers to reference message objects in publisher-owned shared memory. Objects must not be reclaimed while referenced, yet must eventually be reclaimed, with correct handling of crash recovery and Transient Local QoS retention requirements. We propose ipc_shared_ptr, a pub/sub-aware smart pointer for cross-process message lifetime management. ipc_shared_ptr exploits pub/sub structural properties to specialize Birrell’s reference listing, limiting global metadata updates to per-subscriber 0↔1 transitions and achieving an order-of-magnitude reduction in global communication over general-purpose distributed reference counting. We analyze the key metadata management tradeoff: scalability versus implementation simplicity. Owner-driven reclaim offers greater scalability, but concurrent membership changes and reclamation decisions produce races that widen the correctness-verification state space. Single-writer achieves structural atomicity, eliminating this complexity at the cost of a centralized bottleneck. iceoryx2 (owner-driven reclaim) and Agnocast — a true zerocopy ROS 2 IPC middleware sharing the publisher’s heap with subscribers and adopting ipc_shared_ptr with single-writer — embody each architecture. Comparative evaluation at the scale of Autoware — the largest open-source ROS 2 application — confirms that single-writer achieves sufficient scalability: at 200 topics, two subscribers per topic and 100 Hz, Agnocast’s E2E p99.9 is 2.9× lower than iceoryx2’s, justifying implementation simplicity over owner-driven reclaim. Index Terms—Robot programming, Multiprocessing systems, Concurrency control, Low latency communication, Middleware, Publish-subscribe, Memory management, Runtime environment
I. I NTRODUCTION Many autonomous cyber-physical systems such as autonomous driving and robotics systems are built as componentoriented real-time systems [1], where independent nodes exchange messages through publish/subscribe (pub/sub) [2] middleware such as Robot Operating System 2 (ROS 2) [3]. When nodes run as separate processes for fault isolation, Inter Process Communication (IPC) cost directly impacts system performance. True zero-copy communication eliminates all copying including serialization and deserialization, reducing transfer latency, freeing CPU cycles, avoiding temporary memory allocations, and improving timing predictability. In true zero-copy IPC, subscriber processes directly reference message objects constructed on publisher-owned shared memory. iceoryx2 [4] achieves true zero-copy IPC with poolallocated chunks, restricting payloads to self-contained, triv-
‡
TIER IV Incorporated, Japan
ially destructible types while allowing per-message metadata to be embedded within each chunk. Agnocast [5] instead maps the publisher’s heap to shared memory, supporting arbitrary message types including those with heap allocations such as std::vector; however, because subscribers see the publisher’s heap as-is, there is no reserved space for per-message metadata. Agnocast therefore requires an external mechanism for cross-process object lifetime management. Cross-process lifetime management is non-trivial. Processlocal reference counts (as in C++’s std::shared_ptr, which deallocates an object when its in-process reference count reaches zero) are insufficient: whether a message can be reclaimed depends on references held across all processes. Dynamic membership — joins, leaves, and crashes — and Transient Local Quality of Service (QoS), which retains messages for late joiners, add further complexity. A naive global per-message reference count is costly because every reference copy, whether intra- or inter-process, requires a synchronized update. The distributed systems literature has long studied two-level approaches separating process-local from global reference management to reduce coordination costs [6]; we adapt such schemes to publish/subscribe systems. In particular, Birrell’s reference listing [7] is the closest antecedent. In that scheme, the object owner maintains process IDs holding references, limiting global communication to process-granularity transitions. However, such general-purpose methods assume references can propagate between arbitrary processes. In pub/sub, the topic graph determines which processes receive each message, enabling a simpler, more efficient design. This paper proposes ipc_shared_ptr for cross-process object lifetime management in pub/sub systems, exploiting three structural properties: (1) the reference holder set is derivable a priori from topic membership, (2) references flow unidirectionally from publishers to subscribers, and (3) messages are independent deallocation units. The result specializes Birrell’s reference listing to the pub/sub domain: global metadata updates are limited to 0↔1 transitions of each subscriber’s local reference count; in-process copies trigger no global updates. In robotics workloads, where references to a message are copied multiple times within a single process while total process counts are limited, this achieves an order-of-magnitude reduction in global communication over general-purpose methods. Cross-process lifetime management requires per-message metadata accessible to all participating processes, whose place-
© 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Accepted for publication in the 2026 IEEE 29th International Symposium on Real-Time Distributed Computing (ISORC).
ment creates a key tradeoff between scalability and implementation simplicity. In the single-writer approach, a centralized server mediates all metadata access, structurally guaranteeing atomicity. In the owner-driven reclaim approach adopted by iceoryx2 [4], each publisher manages its own metadata without centralized coordination, offering better theoretical scalability at the cost of races between concurrent membership changes and reclamation decisions (Section V-C). Agnocast adopts single-writer; comparative evaluation with iceoryx2 shows it scales to Autoware-class workloads [8], [9], justifying implementation simplicity over theoretical scalability. Contributions. (1) We propose ipc_shared_ptr, a crossprocess object lifetime management mechanism for pub/sub systems. By specializing Birrell’s reference listing to pub/sub, ipc_shared_ptr derives the receiver set from topic membership instead of registering references on each transfer, and bounds the global reference set to current subscribers. We demonstrate feasibility on Agnocast. (2) We comparatively evaluate the single-writer (Agnocast) and owner-driven reclaim (iceoryx2) architectures, and show that the single-writer design achieves comparable scalability at Autoware-class scale. II. BACKGROUND A. Publish/Subscribe Systems Topic-based messaging. Publish/subscribe is a messaging paradigm in which publishers and subscribers communicate through named topics [2]. Publishers send messages without knowledge of which subscribers exist; all current subscribers of that topic receive each published message. A key characteristic is dynamic membership: throughout this paper, the membership of a topic refers to the set of publishers and subscribers currently participating in that topic, which changes as endpoints join, leave, or crash at any time. Quality of Service (QoS). Two QoS parameters [10] are directly relevant to object lifetime management. Durability determines whether messages are retained for late-joining subscribers: under Transient Local, the publisher retains published messages and delivers history to late joiners, whereas under Volatile, messages are delivered only to subscribers present at publish time. Depth, under the Keep Last policy, specifies how many past messages the publisher retains for Transient Local delivery. Even after all current subscribers release their references, the publisher must retain up to Depth messages for future late joiners — directly affecting when message objects can be reclaimed (Section IV). B. Robot Operating System 2 Overview. ROS 2 [3] is the de facto development platform for robotics and autonomous driving, adopting a componentoriented architecture where independent nodes communicate through topic-based pub/sub. Each topic is identified by a name and associated with a message type. Each node contains one or more callbacks, which are triggered upon message reception; a callback may in turn publish messages to other topics, forming system-wide dataflows (Fig. 1).
CB
Node
CB
Topic CB
Publish
CB
Subscribe
CB CB
CB
Callback
CB CB CB
Fig. 1: Publish/subscribe system (Robot Operating System 2). Message types and rosidl. Message types are defined in interface definition files (.msg) and compiled into languagespecific data structures by the rosidl toolchain [11]. Message types containing dynamic containers such as std::vector may undergo reallocation during message construction; this paper refers to these as unsized message types. Nearly all standard ROS 2 message packages (std_msgs, sensor_msgs, geometry_msgs, etc.) contain unsized types [5]. Allocator constraint and Agnocast. True zero-copy IPC requires heap allocations to be redirected to shared memory. In ROS 2 C++, rosidl-generated structs hardcode std:: allocator<void> for all container members, with no mechanism to parameterize the allocator type [11]. Three approaches have been considered, each breaking type compatibility: (1) a custom allocator changes the type signature; (2) a polymorphic allocator resolves the template parameter but breaks container compatibility; (3) making unsized fields implicitly bounded preserves the API but breaks type consistency [12]. See [5] for details. Agnocast sidesteps this by mapping the publisher’s heap itself to shared memory at an identical virtual address offset across publisher and subscriber processes, so that standard rosidl-generated types can be used unmodified [5]. Autoware. Autoware [8], [9] is the largest open-source autonomous driving stack built on ROS 2. Autoware v1.7.1 [13] comprises 223 nodes and 227 topics1 , and serves as the workload baseline in Section VII. The median number of subscribers per topic is 1 (mean 3.4); the five most subscribed topics are vehicle pose estimate (35), coordinate transforms (32), static coordinate transforms (31), HD map (25), and planned route (16). LiDAR point clouds drive the majority of the pipeline at 10 Hz; exceptions include vehicle control commands at 33 Hz and localization/velocity outputs at 50– 100 Hz. Camera inputs operate at 10 Hz, radar at 20 Hz. Point cloud messages span several megabytes per frame, simultaneously consumed by multiple nodes for detection, localization, and planning. III. P ROBLEM S TATEMENT In true zero-copy IPC, subscribers directly reference message objects on publisher-owned shared memory, raising the question of when and how to reclaim them. This section formalizes the system model (Fig. 2) and requirements. 1 Counting only topics with at least one publisher and one subscriber.
Single Host read-only references
Publisher Process (P)
Publisher Process
Subscriber S1
Shared Memory
Subscriber S1
read-only references
S1 Local Count
Message M
count: 3 (shared memory)
copy/drop → local only
M1
M2
M3
Subscriber S2 join
0↔1
Pub Local Count count: 2 (p1, p2)
Global Ref Count
publish(p1) → all copies invalidated
per-subscriber-process bit
Subscriber S3
{ S1, S2 }
Subscriber S2
updated on 0↔1 only
S2 Local Count
leave / crash 0↔1
Reclaimable when:
Metadata
(1) global set = ∅
Data plane (reference tracking)
Control plane (membership)
M1 → { } M3 → { S1 }
Topic T: Pub: { P } Sub: { S1, S2, S3 }
M2 → { S1, S2 }
Fig. 2: System model behind ipc_shared_ptr. A. System Model The target is single-host multi-process pub/sub; networkdistributed environments are out of scope. Subscribers directly reference message objects in publisher-owned shared memory. Processes have separate address spaces and may start, terminate, or crash at any time. Each message is an independent deallocation unit with no inter-object references; all ROS 2 message types satisfy this property. Subscriber processes access these objects in read-only mode, holding references in arbitrary number and releasing them at any time. This paper classifies metadata into two categories: the data plane, which tracks per-message reference holders and reclamation eligibility; and the control plane, which manages topic membership, membership change timing, and late-joiner catch-up positions. In Fig. 2, the data plane records that M1 has no remaining references and is reclaimable, while M2 is still referenced by S1 and S2; the control plane records the membership of topic T and the position from which a late joiner such as S3 should begin receiving messages. B. Requirements A cross-process lifetime management mechanism must satisfy the following requirements. R1 (No premature reclamation). Objects must not be reclaimed while any subscriber holds a reference. With Transient Local QoS, reclamation must additionally be suppressed until Depth retention requirements are met, even when all subscriber references have been released. R2 (No permanent leak). Objects whose references have all been released and whose retention requirements are met must eventually be reclaimed. R3 (Transparency). The complexity of cross-process lifetime management must be hidden from application code, which must be able to use ipc_shared_ptr with std:: shared_ptr-equivalent copy, move, and destruction semantics. R4 (Dynamic membership). R1–R3 must hold across membership changes, including unexpected crashes. Orphaned references from crashed processes must be cleaned up without
count 3→0: notify → remove S1
(2) QoS retention met
count: 1 copy/drop → local only count 1→0: notify → remove S2
Fig. 3: Two-level reference count structure of ipc_shared_ptr. p1, p2 denote distinct ipc_shared_ptr copies in the publisher process to the same message M; publish(p1) publishes M and invalidates all such copies. Of the three counts, only the global reference count belongs to the data plane in Fig. 2; pub/sub local counts reside within each process. violating R1. History delivery to late joiners must execute safely in parallel with reclamation and crash recovery. R5 (Scalability). Metadata management overhead must not substantively degrade performance at Autoware-class scale. R1–R5 apply regardless of the metadata management architecture. The key difference between architectures is the implementation complexity required to achieve them. Section V shows that data plane/control plane separation increases the protocol complexity needed for R1, R2 and R4; Section VII shows that the single-writer approach satisfies R5. Together, these support adopting the single-writer approach. IV. ipc_shared_ptr ipc_shared_ptr manages cross-process message lifetimes in pub/sub systems via two-level reference counting: processlocal counts and membership-aware global tracking. The twolevel structure eliminates the kernel call per reference copy incurred by naive single-level designs such as pre-v2.2.0 Agnocast (Section IV-B). The mechanism is independent of the shared memory design (heap-sharing or chunk-based). Section VI demonstrates ipc_shared_ptr on Agnocast. A. Design ipc_shared_ptr combines a two-level reference count structure with pub/sub-specific ownership semantics (Fig. 3). Publisher-side semantics. A publisher constructs a message via ipc_shared_ptr with std::shared_ptr-equivalent copy, move, and destruction semantics; copies within the publisher process (e.g., p1, p2 in Fig. 3) are tracked by a publisher’s local count. publish() transfers ownership to the middleware; all copies the publisher still holds are invalidated, with subsequent accesses detected as runtime errors. This prevents writes to data being simultaneously read by subscribers, catching bugs during CI/CD and simulation testing. An ipc_shared_ptr whose local count reaches zero without publish() deallocates exactly like std::shared_ptr.2
Subscriber-side semantics. A subscriber accesses each received message through an ipc_shared_ptr that behaves as a std::shared_ptr: copy, move, and destruction semantics are identical from the subscriber’s perspective. In-process copies increment only the process-local count; no cross-process communication occurs. When the local count drops to zero, the subscriber notifies the metadata manager (via syscall in the kernel module implementation) to remove itself from the global reference set, rather than freeing the object. Global reference count. A per-message set of subscriber process IDs, each indicating that the process holds at least one local reference. An entry is added when a subscriber first acquires a reference (at publish time or late-joiner delivery) and removed upon the subscriber’s zero-count notification. Only 0↔1 transitions of the local count trigger global updates; intermediate increments and decrements are invisible globally. The management method for the global reference set — centralized versus distributed — is the subject of Section V. Reclaimable timing. A message becomes eligible for reclamation when two conditions are jointly satisfied: (1) the global reference set is empty, and (2) QoS retention requirements are met — with Transient Local QoS, at least Depth newer messages from the same publisher exist. Actual deallocation occurs at an arbitrary time after both conditions hold. When and by whom the reclamation check is performed depends on the metadata architecture (Section V). B. Relationship to Birrell’s Reference Listing ipc_shared_ptr specializes Birrell et al.’s reference listing [7], the closest antecedent in the distributed reference counting literature [6]. In Birrell’s method, the object owner maintains a set of referencing process IDs (dirtySet); a client issues a dirty Remote Procedure Call (RPC) on first surrogate creation and a clean RPC when the surrogate becomes locally unreachable. This “process-local tracking + owner-managed ID set” pattern maps directly to the two-level structure in Section IV-A. ipc_shared_ptr exploits three structural properties of pub/sub to simplify this pattern: A priori reference set. Birrell requires a dirty RPC per transfer to each new process, since references can propagate between arbitrary process pairs. In pub/sub, topic membership fully determines the receiver set; references do not propagate between subscribers. Dirty RPCs are thus absorbed into publish and membership operations. Bounded global update frequency. Because the reference set is known a priori, a per-subscriber-process bit suffices — set on first local reference, cleared on last. Global updates occur only on 0↔1 transitions, yielding O(subscribers) frequency rather than O(reference copies). No circular references. Messages are independent deallocation units with no inter-object references, structurally 2 A std::unique_ptr-equivalent design is possible, precluding copies before publish and removing the need for invalidation. The Agnocast implementation adopts std::shared_ptr semantics because the existing ROS 2 API permits referencing a message from multiple locations before publish (e.g., publishing the same message to multiple topics), and ROS 2 developers are accustomed to this interface.
TABLE I: Per-message global metadata update frequency. Method
Updates per message Mechanism
Distributed ref. counting O(ref. copies) Per-copy global update Weighted ref. counting [14], [15] Amort. O(1) Weight redistrib. Ref. listing [7] O(proc. transitions) Dirty/clean RPCs ipc_shared_ptr
O(subscribers)
Publish/membership ops
eliminating the circular reference problem left unresolved in Birrell’s work. TABLE I compares per-message global update frequency across methods. Weighted reference counting [14], [15] achieves amortized O(1) by splitting a finite weight among references, but requires a fallback protocol when the weight is exhausted — unnecessary in pub/sub where the receiver set is bounded by membership. Reference listing shares the same asymptotic order as ipc_shared_ptr, but requires explicit dirty/clean RPCs per transfer; ipc_shared_ptr absorbs these into existing publish and membership operations. The practical gap is large in ROS 2: messages are typically copied across multiple callbacks within each subscriber, while subscriber counts remain small (median 1, mean 3.4 in Autoware). V. M ETADATA M ANAGEMENT A RCHITECTURE The data plane and control plane (Section III-A) can be managed anywhere from fully centralized to fully distributed. This section examines two representative extremes — singlewriter and owner-driven reclaim (iceoryx2 [4]) — and analyzes the tradeoff between implementation simplicity and scalability. A. Single-Writer Model A single privileged entity—either a user-space daemon or a kernel module, hereafter server—mediates all metadata access, centralizing both planes under one address space. Because a single writer owns both planes, consistency is structural: no cross-process synchronization protocol is needed, and the implementation reduces to straightforward locking on internal data structures (R1, R2, R4). Internally, the server may use fine-grained locking to allow concurrency among non-conflicting operations (e.g., concurrent receives on the same topic; Section VI-C), while still guaranteeing atomicity where it matters—between membership changes and dataplane operations. Process exit detection and metadata cleanup complete in one place; on publisher crash, the server takes over Transient Local retention, enabling uninterrupted history delivery to late joiners. A kernel module additionally eliminates the intermediate scheduling layers present in daemonbased designs, structurally precluding priority misalignment from intermediate threads (Section VII-C). The tradeoff is a potential scalability bottleneck from the single update point (R5); Section VII quantifies this cost. B. Owner-Driven Reclaim Model Each publisher manages the data plane for its own published messages, as in iceoryx2’s fully decentralized architecture. Publishers maintain the global reference set in locally accessible metadata (e.g., embedded in chunk headers), and subscribers update it directly via shared memory, so reclamation
decisions are made locally without centralized coordination. The control plane, however, cannot be localized: membership information spans multiple processes and must be shared via cross-process synchronization. Cross-process mutexes on shared memory are the straightforward option, but a process crashing while holding the mutex leaves it permanently locked; POSIX robust mutexes (PTHREAD_MUTEX_ROBUST) [16] handle this case, but recovering data structure consistency after a crash remains the application’s responsibility, adding significant implementation complexity. Lock-free alternatives avoid the crashed-lock problem but introduce their own verification challenges. The scalability advantage is that different publishers operate on disjoint data plane metadata, enabling parallel reclamation without the single-writer bottleneck.
TABLE II: Metadata-modifying operations in owner-driven reclaim: lifecycle events for each endpoint type (publisher or subscriber), data-path operations, and subscriber reference release. Operations accessing both planes are potential race sites under separate management.
C. Tradeoffs from Data plane/Control Plane Separation In owner-driven reclaim, reclamation requires jointly reading the data plane and the separately managed control plane. Without atomic access across both planes, race conditions arise. For example, while a publisher verifies that all references to a message have been released, a subscriber may crash and a new subscriber may join concurrently, acquiring a reference via Transient Local history delivery. Because the data plane read and membership update are not atomic, the publisher may observe neither the orphaned nor the new reference, and incorrectly reclaim it. The same race class applies to publisher crashes: the recovery mechanism may free objects while a late joiner concurrently acquires references. A publisher crash further causes a service continuity gap — retention responsibility belongs to the crashed publisher, making Transient Local history permanently unavailable to late joiners, whereas singlewriter transfers retention to the server. Mitigating each race requires handshake protocols whose intermediate states interact with all other concurrent operations. TABLE II enumerates all nine metadata-modifying operations. Six of nine operations touch both planes; any concurrent pair among them is a potential race site. The state space grows combinatorially, making exhaustive correctness verification increasingly difficult with each added protocol. iceoryx2’s development history illustrates this complexity: v0.3.0 (April 2024) fixed race conditions arising under frequent endpoint connection and disconnection [17], and decentralized cleanup of resources left by crashed processes — tracked as a separate effort [18] — required health monitoring infrastructure that arrived in v0.5.0 (December 2024) [19]. In single-writer, both planes are managed by the same entity, structurally precluding the cross-plane races without dedicated protocol design. Section VII evaluates whether the resulting scalability cost is acceptable for realistic workloads.
for ROS 2, demonstrating that the proposed abstraction is realizable on a concrete pub/sub system. Agnocast comprises a user-space library (agnocastlib), a Linux kernel module (agnocast_kmod), and a heap-redirection hook injected via LD_PRELOAD that redirects heap allocations between loan and publish to a per-process shared memory region (see Fig. 4 in [5] for the software stack). Here, loan() is a malloc() call, and the hook redirects it—along with all heap allocations up to publish()—to shared memory; publish() then performs the metadata update and subscriber notification (Section VI-B). Topic discovery is handled internally by the kernel module; interoperability with standard ROS 2 (DDS-based) communication is provided by a separate bridge, described in [5]. The kernel module serves as the single-writer (Section V-A): all data plane and control plane metadata is managed within the module, accessed exclusively through ioctl calls.
VI. I MPLEMENTATION IN AGNOCAST This section implements ipc_shared_ptr (Section IV) on Agnocast v2.3.0 [20] 5 , a true zero-copy IPC middleware 3 Publish accesses only the data plane assuming the publisher caches the subscriber list locally; the cache is refreshed during membership operations, not on every publish. Stale caches are themselves a source of races in ownerdriven reclaim.
#
Operation
1 2 3 4 5 6 7 8 9
Subscriber join (incl. history delivery) Subscriber leave (graceful) Subscriber crash cleanup Publisher join Publisher leave (graceful) Publisher crash cleanup Publish 3 Reclamation check Subscriber reference release
Data plane
Control plane
✓ ✓ ✓
✓ ✓ ✓ ✓ ✓ ✓
✓ ✓ ✓ ✓ ✓
✓
A. Kernel Module Data Structures The module maintains a per-topic data structure protected by a per-topic reader-writer lock; a global reader-writer lock guards the top-level hash table mapping topic names to pertopic structures (Fig. 5). Following the single-writer model (Section V-A), both planes (Section III-A) are merged: the entry tree realizes the data plane, while the endpoint tables and hash table realize the control plane. Each per-topic structure contains the following: Entry tree. A red-black tree of entry records (one per published message) keyed by a monotonically increasing entry ID. Each entry record stores the message’s virtual address and a subscriber bitmap (DECLARE_BITMAP); these two fields constitute the per-message metadata referenced in Section III– Section V. This bitmap is the concrete realization of the global reference count (Section IV-A): bit i is set if and only if the subscriber with topic-local ID i currently holds at least one ipc_shared_ptr reference. A zero bitmap, combined with QoS Depth satisfaction, is the necessary and sufficient condition for reclamation (R1). Endpoint tables. Per-topic hash tables store publisher and subscriber records, each containing a topic-local ID (determining the bit position in every bitmap of that topic), owning PID, and QoS parameters. Subscriber records additionally store a watermark for Transient Local history delivery.
Publisher
agnocast_kmod
Subscriber
Global R/W lock
publish ioctl
Hash Table insert entry, check reclaim
mq_send() × S
topic name → per-topic structure Per-topic R/W lock
— one wakeup per subscriber
Entry Tree red-black tree, keyed by entry_id
epoll_wait returns
entry record
receive ioctl vaddr → ipc_shared_ptr
callback(msg)
Fig. 4: E2E message flow in Agnocast. The subscriber also issues a release ioctl on each 1 → 0 local refcount transition. B. Core Operations This subsection traces how each ipc_shared_ptr operation (Section IV-A) maps to a kernel ioctl (Fig. 4). Publish. The ioctl inserts a new entry record with a zero-initialized bitmap, then scans the publisher’s oldest entries and evicts those whose bitmap is all-zero and that exceed QoS Depth, returning their virtual addresses to user space for deallocation. This realizes the reclaimable timing of Section IV-A, including Transient Local retention (R1). The ioctl also returns the list of current subscriber IDs; user space then sends a zero-length wakeup to each via a persubscriber POSIX message queue (capacity 1, registered with epoll). If the queue is full, the send returns immediately; the subscriber is already scheduled to wake and its next receive drains all pending entries. This O(S) post-publish notification is the dominant cost measured in Section VII. Receive. After wakeup, the subscriber issues this ioctl. The module computes entries since the subscriber’s watermark and, for each, atomically sets the subscriber’s bit in the global reference count bitmap and returns the entry ID and virtual address. On return, agnocastlib constructs an ipc_shared_ptr for each entry with local reference count 1 (R3). Reference release. When an ipc_shared_ptr’s local count reaches zero, agnocastlib issues this ioctl, which atomically clears the subscriber’s bit in the bitmap. No deallocation occurs; the entry becomes eligible for eviction the next time the publisher publishes. Only the local-count 0↔1 transition triggers a kernel call; in-process copies modify only the process-local count (R3). Endpoint registration. Registration inserts a new endpoint record with a fresh topic-local ID. For Transient Local subscribers, the watermark is initialized to deliver the latest Depth retained entries on the first receive (R1). Publisher-side QoS Depth bounds the number of entries retained in the entry tree for that publisher; subscriber-side QoS Depth determines the watermark’s initial offset (how far back a late joiner begins receiving), but does not affect reclamation eligibility. C. Concurrency Control and Scalability The module enforces a strict two-level lock hierarchy: a global reader-writer lock over a per-topic reader-writer lock. TABLE III shows the lock mode per operation.
entry_id
42
vaddr
0x7f2a5400
bitmap
1
0
1
0
⋯
S₀
S₁
S₂
S₃
···
Endpoint Tables Publisher
local_id, PID, QoS, …
Subscriber
local_id, PID, QoS, watermark, … ⋯
Fig. 5: Kernel module data structure layout in Agnocast. Bit i of each entry’s bitmap is set while subscriber i holds at least one reference; a zero bitmap with QoS depth satisfied triggers reclamation. The subscriber table stores a per-subscriber watermark for Transient Local history delivery. Per-topic parallelism (R5, scalability). Publish, receive, and release hold only a read lock on the global lock; with T independent topics, up to T publish critical sections execute concurrently, confining the single-writer bottleneck to intratopic serialization. The receive and release paths use read locks on the per-topic lock as well: the receive path’s writes are either atomic (test_and_set_bit on the subscriber bitmap) or persubscriber (watermark, mmap flag), with at most one receive per subscriber in flight at a time (reentrant callback groups require separate handling). This allows all S subscribers on the same topic to receive concurrently, eliminating intra-topic serialization on the receive side. Only publish takes the pertopic write lock, as it modifies the shared entry tree (insertion and eviction). Section VII quantifies this scalability. TABLE III: Lock acquisition modes per operation. Operation Publish Receive Release Membership change
Global lock
Per-topic lock
READ READ READ WRITE
WRITE READ READ —
Structural atomicity (R4, dynamic membership). Membership changes hold the global write lock, serializing against all concurrent operations. No handshake protocol is required: the single lock structurally guarantees the consistency that owner-driven reclaim must achieve through cross-plane synchronization (Section V-C). Process exit handling. The module detects process exit via a kernel tracepoint and performs cleanup under the same global write lock: orphaned subscriber bits are cleared from every bitmap, and reclaimable entries are evicted (R2). Be-
1.0
0.8
0.8
0.8
0.6
0.6
0.6
0.4
CDF
1.0
CDF
CDF
1.0
0.4 0.2
0.2 Agnocast iceoryx2
0.0 101
Publish latency (us)
102
0.4 0.2
Agnocast iceoryx2
0.0 100
Receive latency (us)
Agnocast iceoryx2
0.0
101
101
102
E2E latency (us)
103
Fig. 6: Publish, receive, and E2E latency for a representative configuration (T = 10, S = 4, R = 100 Hz). cause the server survives publisher crashes, Transient Local history remains available to late joiners (R4) — a property unachievable in owner-driven reclaim where retention responsibility belongs to the crashed publisher (Section V-C).
TABLE IV: Sweep parameters (R = 100 Hz throughout).
VII. E VALUATION This section evaluates single-writer scalability for realistic robotics workloads.4 As shown in Section IV-B, ipc_shared_ptr absorbs the dirty/clean RPCs of Birrell’s reference listing [7] into existing publish and membership operations, yielding a clear per-message communication advantage analytically; we therefore focus the empirical evaluation on the scalability comparison with iceoryx2’s owner-driven reclaim.
Sweep
Variable
Range
Fixed
A B C
T (topics) S (subscribers) T ×S
1–200 1–32 T : 10–100, S: 2–16
S=2 T =10 —
TABLE V: Measured metrics. tpublish denotes the start of publish(); treceive denotes the start of the subscriber callback. E2E latency excludes callback execution time. Metric
Definition
Publish latency
Wall-clock time from loan() through publish () completion, including shared memory allocation, payload construction, publish ioctl, and subscriber notification.
Receive latency
Wall-clock time of the core receive-side ioctl (receive ioctl for Agnocast; receive() for iceoryx2).
E2E latency
treceive − tpublish : full one-way delivery latency.
A. Experimental Design Goal and workload baseline. We evaluate scalability of single-writer against iceoryx2’s owner-driven reclaim across topic count T , subscriber fan-out S, and their combination (publish rate R fixed; TABLE IV). Autoware v1.7.1 (Section II) provides the reference scale: 227 topics, median S=1 (mean 3.4), with a few high fan-out topics up to S=35. Results defensible at this scale justify single-writer for realistic ROS 2 workloads. In Autoware’s typical pipeline, callback processing time ranges from several ms to tens of ms — one to two orders of magnitude larger than IPC latency — so metadata management overhead on the order of µs does not substantively impact end-to-end system performance. Systems and environment. We compare Agnocast (v2.3.0)5 [20] against iceoryx2 (v0.8.1) [4] on an Intel Xeon E2278GE (3.30 GHz, 8 cores/16 threads), 32 GB RAM, Ubuntu 22.04, Linux 6.8, ROS 2 Humble, with all processes under FIFO real-time scheduling at priority 80. To prevent Linux’s default RT bandwidth throttle (a 50 ms enforced gap per 1 s window) from contaminating tail latency, we set kernel.sched_rt_runtime_us=999500. The two systems differ in notification mechanism: Agnocast sends a POSIX MQ message per subscriber after the publish ioctl, waking epoll-based event loops; iceoryx2 subscribers poll 4 Benchmark code, scripts, and reproduction pipeline (Agnocast branch 2.3.0-isorc26): https://github.com/sykwer/isorc26_benchmark. 5 The evaluated build includes one post-release change: the per-topic lock for receive ioctl is relaxed from write to read, enabling concurrent receives on the same topic (TABLE III and Section VI-C). This change will be included in a future Agnocast release.
with receive() at 100 µs intervals. At R=100 Hz, this polling interval is small relative to the message period and not dominant in the results. Benchmark design. A one-publisher-per-topic architecture assigns independent pub/sub processes per topic (T publishers + T ×S subscribers). We use a fixed-size ≈1 KB message; since both systems perform true zero-copy IPC, message size does not affect latency. The fixed size is imposed by iceoryx2’s pool-allocation model, which requires self-contained payloads; Agnocast natively supports arbitrary types, making this benchmark conservative for Agnocast. Each configuration runs for 5 iterations with a 2 s warmup, during which all membership changes complete, followed by 10 s of measurement. Reported p50 and p99.9 are exact percentiles over the full sample set for each configuration (pooled over all iterations and per-process streams), not averages of per-iteration or perprocess percentiles. At large process counts, OS scheduling latency dominates metadata overhead and masks middlewarespecific scalability. We therefore bound the parameter space to keep scheduling effects secondary: on this machine, eventprocessing capacity is empirically ≈140,000 events/s, and all configurations are capped at 60% utilization (84,000 events/s). The sweep dimensions and measured metrics are summarized in TABLE IV and TABLE V, respectively.
50
Agnocast p50 Agnocast p99.9
30
20
20
5
0
0 50
75
100 125 150 175 200
0
Number of topics
Agnocast p50 Agnocast p99.9
Latency (us)
200 150 100
10
15
20
25
Number of subscribers
75
100 125 150 175 200
0
Number of topics
700 500
Agnocast p50 Agnocast p99.9
15
iceoryx2 p50 iceoryx2 p99.9
10
0 5
50
20
0
25
50
75
100 125 150 175 200
Number of topics
Agnocast p50 Agnocast p99.9
iceoryx2 p50 iceoryx2 p99.9
400 300 200 100
0
30
iceoryx2 p50 iceoryx2 p99.9
100
600
5
Agnocast p50 Agnocast p99.9
150
25
50 0
25
30
iceoryx2 p50 iceoryx2 p99.9
200
50
Latency (us)
25
iceoryx2 p50 iceoryx2 p99.9
10
10 0
Agnocast p50 Agnocast p99.9
15
Latency (us)
30
250
Latency (us)
250
25
Latency (us)
Latency (us)
40
iceoryx2 p50 iceoryx2 p99.9
5
10
15
20
25
Number of subscribers
30
0 0
5
10
15
20
25
Number of subscribers
30
Fig. 7: Latency scaling for publish (left), receive (center), and E2E (right) metrics as a function of the number of topics (top row, S = 2) and the number of subscribers (bottom row, T = 10). TABLE VI: Per-operation latency at T =10, S=4, R=100 Hz. p50 (µs) Metric Publish latency Receive latency E2E latency
p99.9 (µs)
Agnocast
iceoryx2
Agnocast
iceoryx2
11.0 3.3 21.6
2.5 0.4 54.3
30.3 9.2 53.0
6.4 2.4 111.6
B. Results Per-operation latency distribution (Fig. 6 and TABLE VI). TABLE VI summarizes per-operation latencies at a representative configuration (T =10, S=4, R=100 Hz). iceoryx2’s per-operation publish and receive latencies are 4– 8× lower at p50, since both paths reduce to shared memory operations whereas Agnocast incurs an ioctl and per-subscriber POSIX MQ notification. At the E2E level, however, Agnocast becomes lower than iceoryx2 by 2.5× at p50 (21.6 vs. 54.3 µs) and 2.1× at p99.9 (53.0 vs. 111.6 µs): iceoryx2’s 100 µs polling interval (Section VII-A) imposes a delivery-latency floor that overwhelms its per-operation advantage at this rate. Topic count scaling — Sweep A (Fig. 7, top row). Both systems’ publish and receive latencies grow modestly with T . Agnocast’s publish p50 rises from 6.1 µs (T =1) to 11.1 µs (T =200) (1.8×); receive p50 stays in 2.5–3.4 µs, confirming the receive ioctl is independent of T . Agnocast’s E2E p50 ranges 15–28 µs and p99.9 stays below 71 µs across all T . iceoryx2’s E2E p50 starts at 53 µs — a floor set by its 100 µs polling interval (Section VII-A) — and grows to 84 µs; p99.9 grows from 104 µs (T =1) to a peak of 272 µs at T =100, then settles to 208 µs at T =200. At T =200, S=2, Agnocast’s E2E p99.9 (71 µs) is 2.9× lower than iceoryx2’s (208 µs) despite
iceoryx2’s faster per-operation paths — the polling-derived floor dominates at this rate. Subscriber count scaling — Sweep B (Fig. 7, bottom row). Agnocast’s publish p50 grows linearly from 5.8 µs (S=1) to 145.0 µs (S=32) — a direct measurement of the O(S) cost of sending one POSIX MQ notification per subscriber per publish (Section VI-B). iceoryx2’s publish also scales with S, from 1.2 to 21.7 µs, since each subscriber owns a separate shared-memory channel that the publisher must enqueue into; however, each enqueue is a userspace memory operation, an order of magnitude cheaper than Agnocast’s per-subscriber syscall. Agnocast’s receive p99.9 stays bounded under 21 µs across the entire sweep (peak 20.7 µs at S=16): the receive path acquires only a per-topic read lock (TABLE III), so all S subscribers execute their receive ioctls concurrently without serialization. For E2E latency, Agnocast’s p50 grows steeply from 15.0 to 292.7 µs (19.5×), while iceoryx2’s grows from 53.1 to 96.7 µs (1.8×). The two systems cross over near S=8 at p99.9 (Agnocast 163.1 µs vs. iceoryx2 134.5 µs): at S=32, Agnocast’s E2E p99.9 (702.1 µs) exceeds iceoryx2’s (247.7 µs) by 2.8×, a regime where the per-subscriber syscall cost of notification overtakes iceoryx2’s polling overhead. Publish latency alone (145 µs) accounts for half of Agnocast’s E2E p50 at S=32, confirming that the bottleneck is the O(S) notification mechanism, not the singlewriter metadata architecture (receive p99.9 is only 16.7 µs). Combined scaling — Sweep C (Fig. 8). Agnocast’s hot zone runs along the high-subscriber edge: (T =40, S=16) reaches 1,000 µs p99.9, driven by the O(S) notification cost; the high-topic low-fan-out region remains cool (T =100, S=2: 39 µs). iceoryx2’s hot zone is pushed further along the same
Agnocast
iceoryx2
103
80
Latency (us)
Number of topics
100
60 40
102
20 10 2
4
8
12 16
2
4
Number of subscribers
8
12 16
Fig. 8: E2E p99.9 latency heatmaps over (T, S) parameter space. edge: (T =40, S=16) reaches 1,992 µs p99.9, driven by polling contention at high subscriber-process counts; (T =100, S=2): 269 µs. Agnocast retains the p99.9 advantage across most of the grid; iceoryx2 is faster only in a narrow band (S=8–12 at T ≤40), where Agnocast’s O(S) syscall cost has grown but iceoryx2’s polling cost has not yet collapsed. C. Discussion Sufficiency for the Autoware workload. At Autowarescale topic counts and typical fan-out (median S=1, mean S=3.4), Agnocast’s E2E p99.9 stays on the order of tens of microseconds — one to two orders of magnitude below Autoware’s callback processing time — and is consistently lower than iceoryx2’s. High fan-out topics are the greater challenge: at S ≈ 35 (the most subscribed Autoware topic), linear extrapolation from Sweep B places Agnocast’s E2E p99.9 on the order of hundreds of microseconds, exceeding iceoryx2 in this regime. Three factors mitigate the impact: first, high fan-out topics are rare (only 5 of 227 Autoware topics have S≥16); second, several of these are low-rate (HD map and static coordinate transforms are published only on change); third, the O(S) cost originates from per-subscriber MQ notification, not the single-writer metadata architecture, and is targeted for a post-v2.3.0 release. Notification mechanism vs. metadata architecture. Both systems incur O(S) publish cost, but the constant differs by an order of magnitude: Agnocast issues an MQ syscall per subscriber (≈4.5 µs/sub), whereas iceoryx2 performs a userspace shared-memory enqueue (≈0.7 µs/sub). This per-subscriber syscall cost — not the single-writer metadata architecture — drives Agnocast’s fan-out scaling regression. Conversely, iceoryx2 incurs a 100 µs polling-interval floor on delivery latency, dominant at low-to-moderate fan-out where Agnocast’s eventdriven wakeup wins. The receive-side read lock (TABLE III) ensures that the single-writer metadata path itself introduces no serialization among subscribers: at S=32, receive p99.9 is only 16.7 µs, comparable to iceoryx2’s 19.9 µs. The single-writer metadata architecture is compatible with either notification mechanism; the choice between event-driven and polling is an independent design axis whose tradeoff depends on workload.
Syscall overhead. The per-operation latency gap (TABLE VI; p99.9 publish: 4.7×, receive: 3.8×) reflects the userkernel transition cost of implementing single-writer as a kernel module. At the E2E level, however, Agnocast is lower than iceoryx2 by 2.5× at p50 and 2.1× at p99.9, confirming that ioctl overhead is dominated by other E2E terms (notification path and polling-interval floor). Kernel module placement also enables kernel-level process exit detection and atomic metadata cleanup (Section VI-C). It further eliminates the intermediate kernel threads that propagate priority misalignment in daemon-based IPC [21] (Section VIII). VIII. R ELATED W ORK Distributed reference counting. ipc_shared_ptr is structurally closest to Birrell et al.’s reference listing [7] among distributed reference counting methods, adapted and specialized for the pub/sub domain. Weighted reference counting [14], [15] established the field, and many variants followed [22], [23]; see [6], [24] for surveys. Other safe memory reclamation schemes such as hazard pointers [25], epoch-based reclamation [26], and RCU [27] enable lock-free reader access to concurrent data structures primarily within a single address space, and do not consider publisher/subscriber membership or QoS-driven retention. In contrast, ipc_shared_ptr specializes Birrell’s structure for the pub/sub domain by exploiting that reference destinations are derivable a priori from membership, that references flow unidirectionally from publishers to subscribers, and that messages form a cycle-free object graph; the structural relationship is detailed in Section IV-B. True zero-copy IPC for ROS 2. TZC [28] achieves zerocopy for dynamically sized arrays via partial serialization but requires message-type-specific implementations and predetermined sizes; LOT [29] uses boost::interprocess for ROS 1 but requires library-specific message formats. Both impose substantial application-code constraints, impractical for large-scale ROS 2 projects. iceoryx1 [30] centralized the control plane via a RouDi daemon; iceoryx2 [4] eliminated it. Both restrict messages to self-contained, statically sized types; the race conditions arising from iceoryx2’s decentralization are analyzed in Section V-C. Fast DDS and Cyclone DDS provide shared memory transports but incur serialization costs and do not support true zero-copy for unsized types; Cyclone DDS integrates iceoryx1 as its backend [31], inheriting the fixedsize restriction. Agnocast [5] sidesteps the allocator constraint by mapping the publisher’s heap to shared memory; this paper addresses its cross-process lifetime management. CROSRT [21] addresses priority inversion in DDS-based ROS 2 IPC by propagating priorities across application, middleware, and kernel layers, the root cause being intermediate kernel threads interposed by the DDS transport. Agnocast’s kernel module structurally eliminates this: ioctl-based interaction bypasses such threads, leaving no propagation path for priority misalignment. A user-space daemon would reintroduce them on every metadata update, distinguishing the kernel module choice from daemon-based alternatives beyond the faulttolerance argument of Section VI-C. Luo et al. [32] propose
a multi-stage zero-copy approach enabling end-to-end zerocopy across processing chains. They note that, at the time of [32], Agnocast’s custom executor precluded native ROS 2 components such as message_filter, forcing non-zerocopy fallback; Agnocast v2.3.0 provides message_filterequivalent functionality within the executor, eliminating this disadvantage. IX. C ONCLUSION We proposed ipc_shared_ptr, a pub/sub-aware two-level reference counting abstraction bounding global metadata updates to per-subscriber 0 ↔ 1 transitions. The key design tradeoff — implementation simplicity versus scalability — favors singlewriter: centralizing all metadata access through a single writer provides structural atomicity across the data plane and control plane, eliminating the cross-plane races that demand complex handshake protocols in owner-driven reclaim. Comparative evaluation against iceoryx2 at Autoware-class workload scale demonstrates that the resulting scalability cost is acceptable, confirming implementation simplicity as the rational choice for realistic robotics workloads. X. ACKNOWLEDGMENT The authors thank all contributors to the development of Agnocast, and in particular Ryuta Kambe and Yutaro Kobayashi for their significant contributions. This research is based on results obtained from a project, Green Innovation Fund Projects / Development of In-vehicle Computing and Simulation Technology for Energy Saving in Electric Vehicles (JPNP21027), subsidized by the New Energy and Industrial Technology Development Organization (NEDO). R EFERENCES [1] T. Ishikawa-Aso, A. Yano, T. Azumi, and S. Kato, “Work in progress: Middleware-transparent callback enforcement in commoditized component-oriented real-time systems,” in Proceedings of IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS). IEEE, 2025, pp. 426–429. [2] P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec, “The many faces of publish/subscribe,” ACM computing surveys (CSUR), vol. 35, no. 2, pp. 114–131, 2003. [3] (2024) ROS 2 documentation. Open Robotics. Accessed Apr. 16, 2024. [Online]. Available: https://docs.ros.org/en/rolling/ [4] Eclipse Foundation, “Eclipse iceoryx2,” https://github.com/ eclipse-iceoryx/iceoryx2, 2024, accessed: 2026-03-03. [5] T. Ishikawa-Aso and S. Kato, “ROS 2 Agnocast: Supporting unsized message types for true zero-copy publish/subscribe IPC,” in Proceedings of International Symposium on Real-Time Distributed Computing (ISORC). IEEE, 2025, pp. 01–10. [6] D. Plainfossé and M. Shapiro, “A survey of distributed garbage collection techniques,” in International Workshop on Memory Management. Springer, 1995, pp. 211–249. [7] A. Birrell, D. Evers, G. Nelson, S. Owicki, and E. Wobber, Distributed garbage collection for network objects. Digital Equipment Corporation Systems Research Center, 1993. [8] S. Kato, E. Takeuchi, Y. Ishiguro, Y. Ninomiya, K. Takeda, and T. Hamada, “An open approach to autonomous vehicles,” IEEE Micro, vol. 35, no. 6, pp. 60–68, 2015. [9] S. Kato, S. Tokunaga, Y. Maruyama, S. Maeda, M. Hirabayashi, Y. Kitsukawa, A. Monrroy, T. Ando, Y. Fujii, and T. Azumi, “Autoware on board: Enabling autonomous vehicles with embedded systems,” in Proceedings of ACM/IEEE International Conference on Cyber-Physical Systems (ICCPS). IEEE, 2018, pp. 287–296.
[10] Open Robotics, “About quality of service settings,” https://docs.ros.org/ en/rolling/Concepts/Intermediate/About-Quality-of-Service-Settings. html, 2024, accessed: 2026-03-03. [11] ——, “About internal ROS 2 interfaces,” https://docs.ros.org/en/rolling/ Concepts/Advanced/About-Internal-ROS-2-Interfaces.html, 2024, accessed: 2026-03-03. [12] ROS 2 Contributors, “Issue #2201: Primitives only zero copy transport,” https://github.com/ros2/rclcpp/issues/2201, 2023, accessed: 2026-03-03. [13] The Autoware Foundation, “Autoware v1.7.1,” https://github.com/ autowarefoundation/autoware/tree/1.7.1, 2025, accessed: 2026-03-03. [14] D. I. Bevan, “Distributed garbage collection using reference counting,” in International Conference on Parallel Architectures and Languages Europe. Springer, 1987, pp. 176–187. [15] P. Watson and I. Watson, “An efficient garbage collection scheme for parallel computer architectures,” in Proceedings of International Conference on Parallel Architectures and Languages Europe. Springer, 1987, pp. 432–443. [16] IEEE and The Open Group, “pthread_mutexattr_getrobust, pthread_mutexattr_setrobust — IEEE std 1003.1-2017,” https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_ mutexattr_getrobust.html, 2018, accessed: 2026-03-03. [17] C. Eltzschig, “Announcing iceoryx2 v0.3.0,” https://ekxide.io/blog/ iceoryx2-0-3-release/, Apr. 2024, accessed: 2026-03-03. [18] ——, “Create decentralized service artifacts cleanup API,” https://github. com/eclipse-iceoryx/iceoryx2/issues/96, Jan. 2024, GitHub Issue #96, eclipse-iceoryx/iceoryx2. Accessed: 2026-03-03. [19] ——, “Announcing iceoryx2 v0.5.0,” https://ekxide.io/blog/ iceoryx2-0-5-release/, Dec. 2024, accessed: 2026-03-03. [20] Autoware Foundation, “Agnocast v2.3.0,” https://github.com/ autowarefoundation/agnocast/tree/2.3.0, 2025, gitHub repository, accessed 2026-04-23. [21] S. Kim, J. Song, K. Lee, S. Oh, and H. S. Chwa, “Cros-rt: Cross-layer priority scheduling for predictable inter-process communication in ros 2,” in Proceedings of IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS). IEEE, 2025, pp. 202–214. [22] J. M. Piquer, “Indirect reference counting: A distributed garbage collection algorithm,” in Proceedings of the International Workshop on Parallel Architectures and Languages Europe (PARLE), ser. Lecture Notes in Computer Science, vol. 505. Springer, 1991, pp. 150–165. [23] B. Goldberg, “Generational reference counting: A reducedcommunication distributed storage reclamation scheme,” in Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI). ACM, 1989, pp. 313–321. [24] S. E. Abdullahi and G. A. Ringwood, “Garbage collecting the Internet: A survey of distributed garbage collection,” ACM Computing Surveys, vol. 30, no. 3, pp. 330–373, 1998. [25] M. M. Michael, “Hazard pointers: Safe memory reclamation for lockfree objects,” IEEE Transactions on Parallel and Distributed Systems, vol. 15, no. 6, pp. 491–504, 2004. [26] K. Fraser, “Practical lock-freedom,” Ph.D. dissertation, University of Cambridge, 2004, technical Report UCAM-CL-TR-579. [27] P. E. McKenney and J. D. Slingwine, “Read-copy update: Using execution history to solve concurrency problems,” in Proceedings of the International Conference on Parallel and Distributed Computing and Systems (PDCS), 1998, pp. 509–518. [28] Y.-P. Wang, W. Tan, X.-Q. Hu, D. Manocha, and S.-M. Hu, “Tzc: Efficient inter-process communication for robotics middleware with partial serialization,” in 2019 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS). IEEE, 2019, pp. 7805–7812. [29] C. Iordache, S. M. Fendyke, M. J. Jones, and R. A. Buckley, “Smart pointers and shared memory synchronisation for efficient inter-process communication in ROS on an autonomous vehicle,” in Proceedings of IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS). IEEE, 2021, pp. 6441–6448. [30] Eclipse Foundation, “Eclipse iceoryx: True zero-copy inter-processcommunication,” https://github.com/eclipse-iceoryx/iceoryx, 2024, accessed: 2026-03-03. [31] Eclipse Cyclone DDS contributors, “Shared memory exchange via Eclipse iceoryx — Eclipse Cyclone DDS documentation,” https://cyclonedds.io/docs/cyclonedds/latest/shared_memory/shared_ memory.html, 2024. [32] X. Luo, X. Jiang, H. Liang, Y. Tang, N. Guan, and W. Yi, “Flexible zero-copy IPC for processing chains in ROS 2,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 2025.