Linux不同速率进程同步：如何保障I2C设备1ms采样率

这问题我之前在嵌入式Linux项目里碰过好几次，核心就是实时采集的硬约束和后端处理的不确定性在消息队列这个同步模型下撞了车——消息队列满了之后的阻塞直接拖垮了1ms的采样节奏。给你几个从易到难的解决方案，你可以根据自己的系统资源和复杂度要求选：

1. 双缓冲+共享内存（最易落地的方案） #

这是我最推荐的入门方案，核心思路是把“同步写入消息队列”改成“异步写入本地缓冲”，让进程A彻底摆脱进程B的速度限制：

• 给进程A分配两块独立的共享内存缓冲区（比如用mmap实现跨进程共享，或者直接在父子进程里继承内存），每块可以存一定数量的采样数据（比如1000个，对应1秒的采样量）。
• 进程A的逻辑：只负责往当前可用的缓冲区写数据，写满后立刻切换到另一块空缓冲区继续写，完全不用等进程B处理。
• 进程B的逻辑：只负责读取已经写满的缓冲区，读完就标记这块缓冲区为“可用”，让A可以再次写入。
• 关键细节：用原子变量（C标准库stdatomic.h里的atomic_int/atomic_flag）来标记缓冲区的状态（空闲/正在写入/待读取），避免多进程竞态问题，而且原子操作的开销几乎可以忽略，不会影响A的1ms采样节奏。

举个简单的代码片段：

// 定义共享内存的缓冲区结构体
#include <stdatomic.h>
typedef struct {
    atomic_int status; // 0:空闲, 1:正在写入, 2:待读取
    float sample_data[1000]; // 存1秒的采样数据
    int write_idx; // 当前写入位置
} SampleBuffer;

SampleBuffer buffers[2]; // 双缓冲

// 进程A的采样逻辑
void process_a() {
    while (1) {
        // 找到空闲的缓冲区
        int target_buf = atomic_load(&buffers[0].status) == 0 ? 0 : 1;
        // 原子抢占缓冲区，标记为正在写入
        if (atomic_compare_exchange_strong(&buffers[target_buf].status, &0, 1)) {
            // 写入当前采样数据
            buffers[target_buf].sample_data[buffers[target_buf].write_idx++] = read_i2c_device();
            // 如果缓冲区写满，标记为待读取，重置写入指针
            if (buffers[target_buf].write_idx >= 1000) {
                atomic_store(&buffers[target_buf].status, 2);
                buffers[target_buf].write_idx = 0;
            } else {
                // 没写满，放回空闲状态
                atomic_store(&buffers[target_buf].status, 0);
            }
        }
        usleep(1000); // 严格1ms采样间隔
    }
}

2. 无锁环形缓冲区（更灵活的细粒度方案） #

如果双缓冲的“整块切换”模式不够灵活（比如你不想等满1000个数据再让B处理），可以用无锁环形缓冲区（循环队列）：

• 用一块连续的共享内存作为环形队列，用两个原子变量分别记录读指针和写指针。
• 进程A永远往写指针位置写数据，写完后原子递增写指针（取模队列容量）；进程B从读指针位置读数据，读完后原子递增读指针。
• 判断队列是否满的逻辑：(write_ptr + 1) % queue_capacity != read_ptr（这里一定要用原子操作读取指针，避免脏读）。
• 优势：内存利用率更高，支持细粒度的读写，只要队列容量足够覆盖B的最大延迟时间（比如B最多卡500ms，就设队列容量为500），A就永远不会被阻塞。

3. 系统调度层面优化（辅助保障） #

配合上面的缓冲方案，再给进程A提权，彻底避免CPU抢占导致的采样延迟：

• 在Linux系统中，把进程A设置为实时优先级，用SCHED_FIFO调度策略，优先级设为比进程B高很多（比如用sched_setscheduler系统调用）。这样即使进程B在占用CPU，A的1ms采样任务也能立刻抢占CPU，保证采样精准性。
• 如果还是想用消息队列，记得把消息队列的打开模式设为O_NONBLOCK，这样A写队列失败时不会阻塞，而是立刻返回，然后把数据临时存在自己的私有缓冲区里，等下次再尝试写入（但这个必须配合前面的缓冲方案，不然会丢数据）。

4. 后端批量处理（降低B的开销） #

进程B的瓶颈大概率在Socket写入的系统调用开销上，优化B的处理速度也能缓解队列压力：

• 让进程B批量读取数据（比如一次读10/50个采样），然后打包成一个数据包再发送给Socket，而不是写一个数据调用一次系统调用。系统调用的上下文切换开销很大，批量处理能直接把B的处理效率提升数倍。
• 用异步IO（比如Linux的epoll、aio_write）处理Socket写入，让B在等待Socket发送的同时可以继续读取数据，避免阻塞在IO上。

总结 #

最稳妥的组合是双缓冲+进程A实时优先级，实现简单，资源开销小，完全能保证1ms的采样率不被拖慢。如果你的系统内存充足，把缓冲区设得大一点（比如存2秒的采样），就算B偶尔卡个1秒也不会影响A的采集。

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