多线程C代码需显式内存屏障吗？pthread代码安全性求证

问题背景与代码示例 #

在Linux平台使用pthread多线程库开发，编译选项为-Ofast -lto -pthread，对以下代码的安全性存在疑问：

// shared global
long shared_event_count = 0;
// ...
pthread_mutex_lock(mutex);
while (shared_event_count <= *last_seen_event_count)
    pthread_cond_wait(cond, mutex);
*last_seen_event_count = shared_event_count;
pthread_mutex_unlock(mutex);

核心疑问 #

• 仅调用pthread系列函数是否足够，是否需要额外添加内存屏障以确保循环中能感知到shared_event_count的变更？
• 无内存屏障时，编译器是否会将shared_event_count优化为仅存于寄存器？
• 为保留优化空间，不用volatile，仅在循环条件处获取最新值是否可行？
• 测试显示代码能感知其他线程的变更，但有没有规范或文档提供明确保证？
• Linux内核的ACCESS_ONCE技巧在该场景下是否必要？

#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))

• pthread_mutex_lock()是否自带内存屏障，编译器能否重排其周边语句？

解答与分析 #

1. pthread互斥锁的内存同步语义（规范保证） #

POSIX标准明确规定，pthread_mutex_lock()和pthread_mutex_unlock()分别对应C标准中的**acquire（获取）和release（释放）**内存屏障：

• 调用pthread_mutex_lock()后，所有后续的内存读取操作必须能看到其他线程解锁该互斥锁后写入的所有内存值；
• 调用pthread_mutex_unlock()前，所有内存写入操作必须同步到内存，不能被编译器重排到解锁之后。

合规编译器（如GCC、Clang）在开启-Ofast -lto时，会严格遵守该语义，不会对锁范围内的内存访问做非法优化。

2. 现有代码的安全性 #

你的代码完全符合C标准与POSIX pthread规范，在任意合规优化编译器下都是安全的：

• 所有对shared_event_count的访问都在互斥锁保护范围内（其他线程修改该变量时必然也持有同一互斥锁，否则属于数据竞争的代码bug）；
• 互斥锁的acquire语义保证了锁内读取的shared_event_count一定是其他线程修改后的最新值，编译器不会将该读取缓存到寄存器重复使用。

3. volatile与ACCESS_ONCE的必要性 #

在该场景下，完全不需要volatile或ACCESS_ONCE：

• 这两种手段仅适用于无锁场景下的共享变量访问，用来强制编译器读取内存中的最新值，避免寄存器缓存优化；
• 互斥锁已经提供了足够的内存同步，编译器会自动处理锁内的内存访问，不会做违规优化。

4. pthread_cond_wait的语义保证 #

pthread_cond_wait()会自动释放互斥锁进入等待，被唤醒后重新获取互斥锁。重新获取锁后同样遵循acquire语义，此时读取shared_event_count必然能看到唤醒线程修改后的最新值，无需额外处理。

5. 编译器语句重排的限制 #

POSIX标准禁止编译器将pthread_mutex_lock()之后的语句重排到锁之前，也禁止将pthread_mutex_unlock()之前的语句重排到锁之后。即使开启-Ofast，合规编译器也不会违反该规则。

总结 #

你的代码是正确且安全的，完全符合规范要求，不需要添加额外的内存屏障、volatile或ACCESS_ONCE。测试结果符合预期是因为规范本身就保证了该场景下的正确性。

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