#ring-buffer #spmc #hft #low-latency

hft-channel

SPMC broadcast channel for HFT and real-time systems

4 releases

Uses new Rust 2024

0.2.1 Dec 10, 2025
0.2.0 Dec 3, 2025
0.1.1 Dec 3, 2025
0.1.0 Dec 3, 2025

#301 in Concurrency

LGPL-3.0-or-later

66KB
873 lines

SPMC broadcast channel for HFT and real-time systems

A lightweight, ultra-low-latency single-producer / multi-consumer broadcast channel designed for use in high-frequency trading (HFT) and other real-time systems.

Provides predictable performance, minimal contention, and carefully controlled memory access patterns. Works for thread-to-thread broadcasting via local memory, or inter-process communication using shared memory.

Crates.io Documentation License: LGPL-3.0-or-later Rust

Features

  • Lock-free single-producer / multi-consumer broadcast channel
  • Seq_no protocol ensures overwrite detection
  • Spin-wait receivers for ultra-low latency
  • Cache-friendly layout (CachePadded)
  • Works between threads, or between processes via shared memory
  • Zero allocations after initialization
  • no_std-friendly design

Spin-Wait Behavior

Receivers use busy-waiting (spin loops) to wait for the producer to complete publishing the next message.

Implications:

  • Lowest possible latency (no OS scheduling)
  • A receiver consumes one logical CPU core while waiting
  • Best when producer and receivers are on the same NUMA node
  • Not ideal for scenarios where power efficiency matters
  • No OS blocking (by design)

This design is intended for HFT, trading engines, matching engines, real-time telemetry, and other performance-critical workloads.

Installation

[dependencies]
hft-channel = "0.1"

Quick Example

use hft-channel::spmc_broadcast::channel;

let (tx, rx) = channel::<u64>("/test", 512);

let (_, payload) = tx.reserve();
*payload = 42;
tx.commit();

let (_, payload) = rx.recv();

Design Overview

The channel tracks state as:

[ dirty (1 bit, MSB) | seq_no (63 bits) ]

Guarantees:

  • At least one slot is always dirty
  • Dirty slot = being written, reserved for writing
  • Clean slot = readable and stable
  • If receiver sees seq_no changed, the slot was overwritten

Pattern:

  1. Sender marks next reserved slot dirty
  2. Sender writes payload into current reserved slot
  3. Sender clears dirty flag of current slot (= commit)
  4. Receiver waits for dirty == false, then copies or peeks

Benchmarks

RUSTFLAGS="-C target-cpu=native" cargo build --release --example bench
./target/release/examples/bench --help
./target/release/examples/bench broadcast -p 1000 -m 2

Testing

cargo test

License

Copyright © 2005–2025 IKH Software, Inc.

Licensed under LGPL-3.0-or-later. See LICENSE or https://www.gnu.org/licenses/lgpl-3.0.html.

Contributing

Contributions are welcome! Please open issues or pull requests on GitHub.

By submitting a contribution, you agree that it will be licensed under the project’s LGPL-3.0-or-later license.

Dependencies

~1MB
~17K SLoC