共享内存本身不提供同步，微秒级延迟需绕过内核调度：依赖std::atomic+自旋等待、缓存行对齐、non-temporal store及systemd沙箱适配等底层优化。
共享内存本身不提供同步，微秒级延迟需要绕过内核调度
共享内存只是让两个进程映射同一块物理内存，读写操作本身是纳秒级的，但“通信”意味着一方写完、另一方立刻知道并读取——这必须靠同步机制。直接用 std::atomic + 自旋等待（spin-wait）是最接近微秒级响应的方式，但代价是 CPU 占用率飙升。别指望 pthread_cond_wait 或 sem_wait，它们进内核、触发上下文切换，一次就几十微秒起步。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
shm_open+mmap创建命名共享内存段，权限设为0666，确保两个服务都能访问 - 在共享区内预留一个
std::atomic<uint64_t></uint64_t>作为序列号（seqno），发送方每次写完数据后原子递增，接收方轮询比对 - 接收方必须用
__builtin_ia32_pause()（x86）或std::this_thread::yield()配合自旋，避免过度抢占流水线 - 禁用 CPU 频率调节（
cpupower frequency-set -g performance），否则自旋延迟波动极大
避免 false sharing：数据结构必须按缓存行对齐
如果发送方和接收方的控制字段（比如 seqno 和 ready flag）落在同一缓存行，哪怕只改一个字节，也会导致整个 64 字节行在 CPU 间反复失效（cache coherency traffic），实测延迟从 0.3μs 拉到 5μs+。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 把 seqno 放在结构体开头，并用
alignas(64)强制对其到缓存行边界 - 发送数据区与控制字段之间留足 64 字节 padding，确保不跨行
- 用
perf stat -e cache-misses,cache-references观察 miss ratio，超过 5% 就要检查布局 - 不要把多个原子变量打包进一个 struct 再对齐——编译器可能重排，单独声明 +
alignas更可靠
munmap 时机错误会导致 segfault，尤其在 systemd 服务中
systemd 默认启用 PrivateTmp=yes 和 ProtectSystem=strict，shm_unlink 可能失败；更危险的是：若一个进程先 munmap，另一个还在读，就会访问非法地址。这不是竞态，是确定性崩溃。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 永不调用
shm_unlink—— 改用shmctl(..., IPC_RMID, ...)在最后一个进程退出前清理 - 用
atexit()注册清理函数，但必须加static bool cleanup_done = false;防止多次调用 - 在 systemd service 文件里显式设置
ReadWritePaths=/dev/shm，否则shm_open返回 -1（EPERM） - 启动时检查
/dev/shm/xxx是否已存在且可读写，而不是依赖O_CREAT | O_EXCL—— 进程崩溃后残留的 shm 段很常见
微秒级实测瓶颈往往在 memcpy 而非共享内存本身
如果你用 memcpy 往共享内存拷贝几百字节，现代 CPU 上它本身就要 100ns+；但更隐蔽的问题是：若源数据在 non-temporal 内存（如大页分配的 buffer），而目标在普通页，CPU 会触发 write-allocate，多出一次 cache line 填充，延迟翻倍。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 发送方尽量复用同一块本地 buffer，避免频繁 malloc/free 导致内存碎片影响 TLB 命中
- 对大于 256 字节的数据，用
__builtin_ia32_movntdq（SSE2）做 non-temporal store，绕过 cache，直写内存 - 接收方读取前加
__builtin_ia32_clflushopt刷掉旧缓存行，避免 stale data - 用
perf record -e cycles,instructions,mem-loads,mem-stores看是否卡在 memory bound
真正卡住微秒级通信的，从来不是共享内存 API，而是你没意识到 CPU 缓存协议、内存屏障语义、以及 systemd 的沙箱限制正在后台悄悄改写你的时序假设。
