RTOS下单向共享内存IPC一写一读场景是否需要使用mutex？

• 你的“进程读写内存时会自动等待”的猜想完全错误，CPU和操作系统都不会对普通内存的基础读写做默认的并发访问控制
• 你当前10ns级的时延场景下，mutex属于完全冗余且绝对禁止使用的组件，其开销会直接破坏你的时延指标
• 你不需要mutex，但需要根据单次传输的数据大小选择轻量的无锁同步机制，避免出现数据撕裂问题

1. 基础内存访问的并发逻辑 #

普通内存的读写是纯用户态、纯CPU层面的操作，操作系统不会做任何干涉，也不存在自动等待的机制：

• 如果你的单次读写的数据单元满足「地址对齐 + 大小不超过当前CPU架构的原子访问宽度」（比如32位CPU的4字节、64位CPU的8字节），那么单单元的读写是硬件层面原子的，不会出现半写半读的损坏问题
• 如果单次传输的数据超过原子宽度（比如结构体、长缓存），写操作会被拆分为多条CPU指令执行，读进程完全可能读到一半旧数据一半新数据，也就是数据撕裂，这种情况必须做同步，但不需要用到mutex

2. 为什么mutex不适合你的场景 #

mutex是操作系统提供的重量级同步原语，其调用涉及系统调用、内核上下文切换、线程调度等操作，最低开销也在数百纳秒到微秒级别，远高于你要求的10ns级时延精度，用mutex反而会直接导致你的实时例程时延超标。

3. 适合你场景的同步方案 #

针对单写单读的单向共享内存通道，推荐用纳秒级开销的无锁同步方案，完全不需要mutex：

• 方案1：如果单次写入数据块小于等于CPU原子访问宽度且地址对齐，只需在写完数据后原子更新一个顺序计数器，读进程通过判断计数器的变化确认数据写入完成再读取即可
• 方案2：如果单次写入数据块较大，使用无锁环形缓冲区（Lock-Free Ring Buffer），配合对应CPU架构的内存屏障指令（比如x86的sfence/lfence、ARM的dmb）防止指令重排，就能保证读写一致性，同步开销仅几纳秒

内容的提问来源于stack exchange，提问作者Chanwoo Ahn