Linux共享内存多进程变量同步异常问题咨询

问题背景 #

在Linux环境下通过共享内存实现进程间数据共享，定义的数据结构如下：

struct shared_cfg {
    volatile uint32_t idx;
    volatile uint32_t cfg_lock;
    ...
};

程序需求 #

• 不同进程每次需获取唯一的idx值；
• 进程P1修改idx后，P2需读取新值并更新；
• 后续P1读取P2更新后的新值，循环往复。

异常现象 #

并发量升高时，P2偶尔会读取到idx的旧值，导致P1与P2获取到相同的idx值。错误日志示例：

P1: get lock 
P1: idx is 1; update idx to 2 
P1: unlock

P2: get lock 
P2: idx is 2; update idx to 3 
P2: unlock 

... 
P1: get lock 
P1: idx is 63; update idx to 64 
P1: unlock

P2: get lock 
P2: idx is 63; update idx to 64 
P2: unlock 

当前实现代码 #

锁操作代码

typedef volatile uint32_t lock_t;

void lock_idx(lock_t *lock)
{
    uint32_t old_lock = 0;
    do {
        old_lock = __sync_val_compare_and_swap(lock, 0, 1);
        if (old_lock == 1)
            usleep(10*1000);
        else
            break;
    } while (old_lock == 1);
}

void unlock_idx(lock_t *lock)
{
    __sync_lock_test_and_set(lock, 0);
}

// 初始idx值
uint32_t idx = 0;

P1/P2修改后代码

lock_idx(&cfg_lock);
_mm_mfence();
idx = idx + 1;
_mm_mfence();
unlock_idx(&cfg_lock);

用户尝试插入_mm_mfence()内存屏障后问题仍存在，需解决多进程共享内存的同步异常。

问题根源分析 #

1. 锁实现的内存语义缺陷：unlock_idx使用__sync_lock_test_and_set不符合解锁的内存语义，无法保证临界区内的修改对其他进程可见；锁获取时也缺少读屏障，无法确保后续读取到共享内存的最新值。
2. idx操作的潜在错误：若代码中idx是进程本地变量而非共享内存中的变量，修改后无法同步到其他进程，这是高频错误点。
3. 内存屏障位置错误：_mm_mfence()的插入位置未配合锁的语义，无法解决核心的可见性问题。

解决方案 #

方案1：修复自定义锁的内存语义 #

自定义锁必须保证获取锁后的读屏障和释放锁前的写屏障，确保临界区操作的内存可见性。

修正后的锁代码

typedef volatile uint32_t lock_t;

void lock_idx(lock_t *lock)
{
    // 自旋等待锁，使用sched_yield()减少CPU占用
    while (__sync_lock_test_and_set(lock, 1)) {
        while (*lock == 1) {
            sched_yield();
        }
    }
    // 读屏障：确保后续读取共享内存为最新值
    __sync_synchronize();
}

void unlock_idx(lock_t *lock)
{
    // 写屏障：确保临界区修改已刷入内存
    __sync_synchronize();
    // 使用专门的解锁原子操作，语义更准确
    __sync_lock_release(lock);
}

修正后的业务代码

// 必须操作共享内存中的idx，而非本地副本
lock_idx(&cfg->cfg_lock);
cfg->idx = cfg->idx + 1;
unlock_idx(&cfg->cfg_lock);

方案2：使用POSIX进程间互斥锁 #

自定义锁易出错，推荐使用Linux原生的POSIX共享互斥锁，其内置完善的内存可见性和互斥保证。

步骤1：修改共享内存结构

struct shared_cfg {
    pthread_mutex_t mutex;
    volatile uint32_t idx;
};

步骤2：初始化共享互斥锁

// 映射共享内存后执行初始化
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
// 设置互斥锁支持进程间共享
pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);
pthread_mutex_init(&cfg->mutex, &attr);
pthread_mutexattr_destroy(&attr);
cfg->idx = 0;

步骤3：进程业务代码

pthread_mutex_lock(&cfg->mutex);
cfg->idx += 1;
pthread_mutex_unlock(&cfg->mutex);

方案3：直接使用原子操作递增idx #

若仅需原子递增idx，可完全跳过锁，使用原子操作保证可见性和原子性，性能最优。

GCC内置原子操作

// 原子递增共享内存中的idx，返回递增后的值
uint32_t new_idx = __sync_add_and_fetch(&cfg->idx, 1);

C11标准原子操作

#include <stdatomic.h>

// 修改共享内存结构为原子类型
struct shared_cfg {
    atomic_uint32_t idx;
};

// 原子递增
uint32_t new_idx = atomic_fetch_add(&cfg->idx, 1) + 1;

关键注意事项 #

• 必须确保操作的是共享内存中的变量，禁止将共享内存值复制到本地变量修改后再写回，否则必然导致数据不一致。
• 优先使用Linux原生同步原语（互斥锁、原子操作），避免自行实现锁机制带来的语义陷阱。
• 内存屏障需配合锁或原子操作的语义使用，盲目插入无法解决核心问题。

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