Linux下Python3双独立并行脚本异步数据共享方案选型咨询

核心约束拆解 #

• 双独立Python3脚本运行于Linux环境
• 任务1：以USB IO为主，高频更新numpy float32类型变量，需尽可能降低运行停顿
• 任务2：以串口、文件IO为主，低频异步读取任务1的内存值，读取完成后立即重置对应变量
• 排除方案：文件通信（无法满足读完即重置的原子性要求）

不优先选用的常见方案说明 #

• 纯threading模式：两个任务虽然以IO为主，但任务1对实时性敏感，Python GIL会在任务2触发IO系统调用切换、偶发计算时，导致任务1出现不可控停顿，无法满足低延迟要求。
• asyncio模式：两类硬件IO（USB、串口）若未做专门的异步驱动封装，反而会引入额外适配层开销，甚至因事件循环阻塞拖慢任务1的采集节奏，投入产出比极低。
• stdin/stdout管道通信：传输二进制numpy数组需要额外做序列化/反序列化，且管道读写的原子性保障极弱，很难实现“读完即重置”的无竞态逻辑。
• 类DDS这类重型中间件方案：对仅涉及双进程的极简场景属于过度设计，部署、运维成本远超实际收益。

最优落地方案：基于multiprocessing原生能力的共享内存原子通信 #

该方案完全匹配场景需求，无第三方依赖，实现门槛极低：

实现逻辑 #

• 用Python3标准库的multiprocessing.shared_memory.SharedMemory开辟独立物理共享内存段，将numpy float32变量直接映射到该内存段，两个独立进程可直接操作同一块物理内存，完全没有序列化/反序列化开销，任务1更新值的速度和操作自身类变量没有差异。
• 搭配multiprocessing.Lock()实现跨进程原子互斥锁，刚好满足“读取后立即重置”的要求：
  1. 任务1持续采集过程中，每次更新共享内存里的numpy值时仅短暂持有锁，写完立刻释放，锁的持有时间通常为微秒级，对采集流程几乎无影响。
  2. 任务2异步发起读取时，获取同一把锁，将共享内存里的数值拷贝到自身本地变量，拷贝完成后立刻将共享内存对应位置重置为初始值，随后释放锁。
• 两个进程完全独立，各自持有独立的Python GIL：任务2的串口、文件IO操作完全不会抢占任务1的GIL资源，从机制上杜绝了任务1被意外卡顿的问题。

方案适配性说明 #

• 任务1的停顿开销极低：任务1仅在写入共享内存时需要持有微秒级的短锁，开销比单进程内的线程锁还小，完全满足“尽可能降低停机时长”的要求，且numpy数组直接映射共享内存，高频更新无性能损耗。
• 原子性保障可靠：依靠跨进程互斥锁，读写操作完全互斥，不会出现“任务1刚写入新值、任务2读到一半时重置操作覆盖新数据”的竞态问题，完全规避了文件通信的原子性缺陷。
• 适配IO密集场景：两个进程是独立的操作系统调度单元，USB IO、串口IO、文件IO这类系统调用可被内核正常调度，不会因Python层锁或GIL产生互相拖累。
• 部署成本极低：全部基于Python3标准库实现，无需安装额外第三方中间件，对不熟悉Linux环境的开发者友好，部署难度和普通Python脚本无差异。

避坑提醒 #

• 严格控制锁的持有时长：任务1仅在把numpy值复制到共享内存段的过程中持有锁，不要在锁持有期间执行USB采集这类耗时IO操作；任务2仅在拷贝数值、重置共享内存值的过程中持有锁，不要在锁持有期间执行串口发数、写文件这类耗时操作，将锁的持有时间压缩到微秒级，就不会对任务1的实时性产生影响。
• 不需要引入concurrent.futures：两个脚本是长期持续运行的独立进程，不属于短时任务池调度场景，concurrent.futures的任务调度逻辑对该场景属于冗余设计，可直接用两个独立Python脚本，启动时通过一个极简引导脚本提前创建共享内存段和锁，避免两个脚本启动时抢占内存段即可。

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