项目仓库: cpp_py_shmbuf (C++14 header-only, Python 3.8+) 参考设计: ringbuffer (lock-free SPSC 模式) 对标方案: cpp-ipc (MPMC 方案) 典型应用: 工业视觉、激光雷达融合、边缘计算网关
1. 问题域: 为什么需要共享内存 IPC
1.1 工业视觉的架构约束
典型工业视觉系统采用分工设计:
[相机]
↓ USB3.0 / GigE
[C++ 驱动层] (低延迟采集，NEON 加速预处理)
↓ IPC
[Python 应用层] (OpenCV, TensorFlow, 算法灵活)
↓
[云端/本地存储]
为什么这样分工:
- C++ 采集: 接管相机驱动、硬件同步、帧率控制，毫秒级精度
- Python 处理: 快速原型迭代，丰富的 AI/CV 库 (TensorFlow, OpenCV)
- IPC 瓶颈: 进程边界的数据传递，1080p BGR 帧 = 6.2 MB，30 FPS = 180 MB/s
1.2 四种 IPC 方案的对比
1080p BGR 帧 (1920×1080×3 = 6.2 MB, 30 FPS):
| 方案 | 机制 | 拷贝次数 | 序列化开销 | 延迟 | 可行性 |
|---|---|---|---|---|---|
| TCP socket | 内核缓冲 | 4 (user→kernel→kernel→user) | 无 | 低 | 勉强 (CPU 30%+) |
| Unix domain socket | 内核缓冲 | 2 | 无 | 低 | 可行 (CPU 15%) |
| Protobuf + TCP | 编解码 | 2 + 编码 | 高 (6MB→10ms) | 高 | 不可行 (CPU 50%+) |
| 共享内存 | 虚拟地址映射 | 0 (同一物理页) | 无 | 纳秒 | 理想 (CPU <1%) |
关键区别:
- 前三种方案都涉及内核态/用户态切换或序列化编解码
- 共享内存: 两个进程的虚拟地址指向同一块物理内存，写入方的
memcpy对消费方立即可见，无内核参与，无数据拷贝
1.3 为什么不用现成的 IPC 库
| 库 | 问题 | 成本 |
|---|---|---|
| Boost.Interprocess | 编译慢 (30+ 分钟)、部署复杂、仅 C++ 支持 | 高 |
| zeromq | MPMC 设计过度、引入消息队列复杂性 | 中 |
| gRPC | 网络 RPC 框架，IPC 只是副产品，序列化开销存在 | 高 |
| Redis | 外部进程依赖、不适合嵌入式 | 高 |
cpp_py_shmbuf 的定位: 仅针对 SPSC (Single Producer, Single Consumer) 场景的最小可行实现，零依赖，跨语言原生支持。
2. 为什么这样做: 设计约束分析
2.1 跨语言的原子性约束
C++ 的 std::atomic<uint32_t> 在共享内存中对 Python 不可见。Python 的 struct.pack_into 操作的是原始字节，无法理解 C++ 原子操作的语义。
共享内存是 POD (Plain Old Data)，不能包含 C++ 对象。
解决方案: 原始字节 + 约定协议
// C++ 端: 原始 uint32_t
struct RingHeader {
uint32_t head; // Little-endian, producer 写
uint32_t tail; // Little-endian, consumer 写
uint32_t capacity; // 2 的幂, 只读
uint32_t reserved; // 对齐填充
};
// Python 端: struct.pack_into
struct.pack_into('<I', buf, 0, head_value) # 同样的小端 uint32
内存屏障保证:
- C++ 端:
atomic_thread_fence(acquire/release)在关键操作前后插入屏障 - Python 端: CPython GIL (全局解释器锁) + x86/ARM 上对齐
uint32写入天然原子性
2.2 消除竞态的 buf_full flag
早期设计用 buf_full 标志位区分 "缓冲区空" 和 "缓冲区满"（两者都是 head == tail）:
empty: head == tail && !buf_full
full: head == tail && buf_full
这个 buf_full 被生产者和消费者同时读写，容易竞态:
[时刻 1] Producer 读 head = 100, tail = 100, buf_full = false (发现缓冲区空)
[时刻 2] Consumer 读 head = 100, tail = 100, buf_full = false (发现缓冲区空)
↓ (网络延迟、CPU 调度抖动)
[时刻 3] Producer 写入一条消息，设 buf_full = true，更新 head = 108
[时刻 4] Consumer 继续执行，但已过时的状态导致错误处理
新设计: 借鉴 ringbuffer 的单调递增索引
available_to_read = head - tail // 可读字节数
available_to_write = capacity - (head - tail) // 可写字节数
empty: head == tail
full: (head - tail) == capacity
关键优势:
- 索引单调递增, 永不重置为 0
- 自然溢出安全:
uint32_t自然溢出在 4GB 处，对于 MB 级缓冲区完全安全 - 消除 flag: 用数学关系（差值）代替竞态 flag，天然避免竞态
数学证明:
假设 capacity = 16 (mask = 0xF)
写入 10 字节:
head = 0, tail = 0, available = 0 → 16 字节
写入后: head = 10, tail = 0, available = 10 字节
再写入 8 字节:
head = 10, tail = 0, available = 10 → 6 字节 (不足，拒绝)
自然溢出场景 (head 已达到 uint32_max):
head = 4294967290, tail = 4294967280
available = 4294967290 - 4294967280 = 10 字节 ✓ (正确)
自动溢出后:
head = (4294967290 + 10) % 2^32 = 4, tail = 4294967280 (仍是旧值，稍后会读到新的 tail)
available = 4 - 4294967280 = 4 - 4294967280 (u32 减法)
= 4 + (2^32 - 4294967280) = 4 + 16 = 20... (不对?)
实际上 u32 减法是定义好的:
a - b (mod 2^32) 等于 a + (~b + 1) mod 2^32
当 head 大循环回来时，tail 也应该跟着大循环，差值始终正确。
2.3 消息格式的设计
为了支持变长消息，采用 长度前缀 格式:
[4 字节 LE 长度][payload]
例: 发送 "hello" (5 字节)
共享内存: [05 00 00 00] [h e l l o]
(Little-endian 5)
为什么是 4 字节而非变长编码:
- 固定大小，无需扫描，快速
- 便于 Python
struct.unpack直接解析 - 足以表示 2GB 单条消息（4GB 容量的缓冲区实际容量会更小）
3. 设计方案: 架构与实现
3.1 共享内存布局
总大小 = N + 16 (N 必须是 2 的幂, 如 1048576 = 1MB)
┌─────────────────────────────────────────────────┐
│ 偏移 0-3: head (uint32_t LE) │
│ Producer 写, Consumer 读 │
│ 单调递增索引，用于发信号 │
├─────────────────────────────────────────────────┤
│ 偏移 4-7: tail (uint32_t LE) │
│ Consumer 写, Producer 读 │
│ 单调递增索引，用于流控 │
├─────────────────────────────────────────────────┤
│ 偏移 8-11: capacity (uint32_t LE) │
│ 创建时写入，之后只读 │
│ = N (数据区大小) │
├─────────────────────────────────────────────────┤
│ 偏移 12-15: reserved (对齐填充) │
├─────────────────────────────────────────────────┤
│ 偏移 16-(16+N-1): data area │
│ 环形缓冲数据区 │
│ 存储 [4B len][payload] 格式消息 │
└─────────────────────────────────────────────────┘
设计权衡:
- head/tail 分别由单端独占写入: 天然避免 false sharing (不需要锁)
- capacity 只读: 避免运行时修改，简化同步逻辑
- 16 字节头部: 无缓存行对齐 (arm-64 缓存行 64B，无必要)
3.2 C++ 实现框架
namespace shm {
// 跨平台共享内存
class SharedMemory {
// POSIX: shm_open + mmap
// Windows: CreateFileMappingA + MapViewOfFile
// RAII: 析构时 munmap / UnmapViewOfFile
};
// 字节级环形缓冲 (SPSC, lock-free)
class ByteRingBuffer {
// 绑定到共享内存
ByteRingBuffer(void* base, uint32_t size, bool is_producer);
// Producer API
bool Write(const void* data, uint32_t len);
uint32_t WriteableBytes() const;
// Consumer API
uint32_t Read(void* out, uint32_t max_len);
bool HasData() const;
private:
// 原始指针, 无 C++ 对象
RingHeader* header_;
uint8_t* data_;
uint32_t mask_;
};
// 高层 API
class ShmProducer {
ShmProducer(const char* name, uint32_t capacity);
bool Write(const void* data, uint32_t len);
};
class ShmConsumer {
explicit ShmConsumer(const char* name);
uint32_t Read(void* out, uint32_t max_len);
};
} // namespace shm
3.3 Python 实现
import multiprocessing.shared_memory as mm
import struct
class ByteRingBuffer:
HEADER_SIZE = 16
def __init__(self, buf: memoryview, is_producer: bool = False):
self.buf = buf
self.mask = struct.unpack_from('<I', buf, 8)[0] - 1
self.is_producer = is_producer
def write(self, data: bytes) -> bool:
"""Write [4B len LE][payload]"""
head = struct.unpack_from('<I', self.buf, 0)[0]
tail = struct.unpack_from('<I', self.buf, 4)[0]
available = self.mask + 1 - (head - tail)
total = len(data) + 4
if available < total:
return False
# Write length prefix
struct.pack_into('<I', self.buf, self.HEADER_SIZE + (head & self.mask), len(data))
# Write payload (处理 wrap-around)
self._write_bytes(head + 4, data)
# Update head (Python GIL + aligned write = atomic)
struct.pack_into('<I', self.buf, 0, head + total)
return True
def read(self) -> Optional[bytes]:
"""Read one message"""
tail = struct.unpack_from('<I', self.buf, 4)[0]
head = struct.unpack_from('<I', self.buf, 0)[0]
if head - tail < 4:
return None # Not enough for length prefix
# Read length
msg_len = struct.unpack_from('<I', self.buf,
self.HEADER_SIZE + (tail & self.mask))[0]
if head - tail < 4 + msg_len:
return None # Not enough for payload
# Read payload
payload = self._read_bytes(tail + 4, msg_len)
# Update tail
struct.pack_into('<I', self.buf, 4, tail + 4 + msg_len)
return payload
class ShmProducer:
def __init__(self, name: str, capacity: int):
self.shm = mm.SharedMemory(name=name, create=True,
size=capacity + 16)
# Initialize header
self.ring = ByteRingBuffer(self.shm.buf, is_producer=True)
def write(self, data: bytes) -> bool:
return self.ring.write(data)
class ShmConsumer:
def __init__(self, name: str):
self.shm = mm.SharedMemory(name=name, create=False)
self.ring = ByteRingBuffer(self.shm.buf, is_producer=False)
def read(self) -> Optional[bytes]:
return self.ring.read()
3.4 内存序保证
C++ Producer 写入:
bool ByteRingBuffer::Write(const void* data, uint32_t len) {
// [Step 1] 读本端索引 (relaxed, 无需屏障)
uint32_t head = header_->head;
// [Step 2] 获取对端索引前的屏障 (acquire)
std::atomic_thread_fence(std::memory_order_acquire);
uint32_t tail = header_->tail;
// [Step 3] 检查可写空间
uint32_t available = capacity_ - (head - tail);
uint32_t total = len + 4;
if (available < total) return false;
// [Step 4] 写数据 (memcpy, 非原子)
WriteRaw(head, &len, 4); // length prefix
WriteRaw(head + 4, data, len); // payload
// [Step 5] 写本端索引前的屏障 (release)
std::atomic_thread_fence(std::memory_order_release);
// [Step 6] 发信号给对端 (release 后)
header_->head = head + total;
return true;
}
Python Consumer 读取:
def read(self) -> Optional[bytes]:
# Python GIL 已保证序列化，但为了对齐 C++ 的语义，
# 我们按照 acquire-release 的顺序读取
# [Step 1] 读本端索引 (own variable, no barrier)
tail = struct.unpack_from('<I', self.buf, 4)[0]
# [Step 2] Implicit barrier (GIL + aligned read is atomic on x86/ARM)
head = struct.unpack_from('<I', self.buf, 0)[0]
# ... 读消息 ...
# [Step 3] 写本端索引 (with implicit barrier)
struct.pack_into('<I', self.buf, 4, new_tail)
4. 性能与可行性
4.1 吞吐量基准 (x86-64, GCC 13, -O2)
| 消息大小 | 吞吐量 (单线程) | 跨线程吞吐 | 延迟 (r/w) |
|---|---|---|---|
| 64 B | 2.1 GB/s (35M msg/s) | 0.5 GB/s (9M msg/s) | 11 ns |
| 1 KB | 3.2 GB/s (3.4M msg/s) | 3.9 GB/s (4.1M msg/s) | 52 ns |
| 4 KB | 3.2 GB/s (830K msg/s) | 5.7 GB/s (1.5M msg/s) | 169 ns |
| 6 MB (1080p) | 2.5 GB/s (423 FPS) | 4.4 GB/s (763 FPS) | - |
1080p 30 FPS 的可行性:
- 所需带宽: 1920×1080×3 × 30 = 180 MB/s
- 跨线程能力: 4.4 GB/s
- 占用比例: 180 / 4400 = 4%
- 估计 CPU 占用: < 1% (剩余容量充足)
4.2 对标 socket 方案
TCP socket (loopback) 方案:
- 内核态/用户态切换 2 次
- 缓冲区拷贝 4 次
- 1080p 30 FPS: CPU 占用 30-50%
共享内存方案:
- 无内核态切换
- 无数据拷贝
- 1080p 30 FPS: CPU 占用 < 1%
5. 使用场景
5.1 工业视觉 (1080p/4K 实时处理)
[GigE 相机]
↓
[C++ 驱动: 采集 + 预处理]
↓ (共享内存, < 1% CPU)
[Python: OpenCV + TensorFlow]
↓
[本地/云端推理]
关键指标: 30 FPS 无帧丢失，端到端延迟 < 50ms
5.2 多模态传感器融合 (LiDAR + 相机 + 毫米波)
[LiDAR 驱动 (C++)] → 点云 (20Hz, 100KB)
↓
[共享内存总线]
↓
[相机驱动 (C++)] → 图像 (30Hz, 6MB) → [Python 融合算法]
↓
[毫米波驱动 (C++)] → 雷达数据 (100Hz, 1KB)
多个生产者写入不同的消息到共享内存，Python 端按时间戳融合。需要 MPMC 环形缓冲 (超出本项目范围，可用 cpp-ipc)。
5.3 边缘计算网关
[传感器数据采集 (C++, 高频)]
↓ (共享内存, 零拷贝)
[本地推理 (Python + ONNX)]
↓ (可选压缩、加密)
[云端上传 (Python + 网络)]
数据面用共享内存 (高速, 低延迟)，控制面用 gRPC/socket (配置、统计)。
6. 跨语言协议约束
为了确保 C++ 和 Python 的数据一致性，必须遵守以下约定:
| 约束 | 原因 | 违反后果 |
|---|---|---|
| 同一架构 (不跨字节序) | uint32_t LE 直接读写 | 数据损坏 |
| 对齐 uint32 读写 | x86/ARM 对齐写原子 | 撕裂写 (partial write) |
| CPython (有 GIL) | struct.pack_into 的原子性保证 | PyPy 下竞态 |
| SPSC 模式 | 只有一个生产者、一个消费者 | 竞态导致数据丢失 |
| 同一物理机 | 共享内存仅限单机 | 网络通信需改方案 |
若需跨越这些约束:
- 多消费者 → cpp-ipc 的 MPMC
- 网络通信 → zeromq / gRPC
- PyPy 支持 → 加
multiprocessing.Lock - 跨字节序 → 显式序列化 (Protobuf 等)
7. 总结与对标
cpp_py_shmbuf 的定位: 工业嵌入式中 SPSC 场景的最优 IPC，专注于零拷贝、零依赖、跨语言原生。
| 特性 | cpp_py_shmbuf | Boost.Interprocess | cpp-ipc | Socket |
|---|---|---|---|---|
| 零拷贝 | ✓ | ✓ | ✓ | ✗ (2-4 拷贝) |
| C++ 依赖 | 无 | Boost (重) | 无 | POSIX |
| Python 支持 | ✓ (原生) | ✗ | ✗ | ✓ |
| SPSC | ✓ (优化) | ✓ | ✓ | - |
| MPMC | ✗ | ✓ | ✓ | - |
| 编译耗时 | 秒级 | 分钟级 | 秒级 | - |
| 推荐场景 | SPSC 实时 | 通用共享内存 | MPMC 实时 | 远程通信 |
相关技术参考:
- ringbuffer 设计 -- 单调递增索引、power-of-2 mask
- 激光雷达 Pipeline -- 真零拷贝的 Handle 传递
- newosp 并发架构 -- AsyncBus MPSC 消息总线
