线程内存同步疑问：SetEvent与WaitForSingleObject是否足够？

这个问题问到点子上了——很多人会以为用事件同步线程执行顺序就足够解决内存可见性问题，但其实这里藏着容易被忽略的细节。先直接给你结论：你的现有代码不完全安全，存在编译器优化导致的指令重排风险；不过不需要额外的互斥量，通过简单的调整就能保证内存同步。

下面一步步拆解：

1. Windows事件的内存屏障是有用的，但不够 #

Windows的Event同步原语自带内存屏障语义：

• 主线程调用SetEvent时，这个操作是带有release语义的——它会强制把SetEvent之前的所有内存写入（包括你给buf赋值的操作）刷新到主内存，还会禁止CPU把后续操作重排到SetEvent之前。
• 子线程调用WaitForSingleObject成功返回时，这个操作是带有acquire语义的——它会让当前线程的CPU缓存失效，重新从主内存读取数据，同时禁止CPU把之前的操作重排到Wait之后。

从硬件层面的内存同步来说，这一对操作其实已经能保证子线程看到主线程在SetEvent前的所有内存更新，包括buf的赋值。那问题出在哪？

2. 编译器优化可能搞破坏 #

如果你的T::buf没有被声明为volatile，编译器可不知道这是个跨线程访问的变量。它可能会觉得buf = p和SetEvent之间没有依赖关系，偷偷把SetEvent的调用提前到buf = p之前——这就完蛋了，子线程被唤醒时，buf还没被正确赋值，直接操作肯定会崩溃。

3. 两种简单的修复方案 #

你不需要额外加互斥量（除非你还有多个线程同时写buf或者缓冲区数据的场景），选下面一种就行：

方案一：给buf加volatile修饰 #

在T类里把buf声明成volatile int* buf;。volatile关键字就是告诉编译器：这个变量是“易变”的，可能被其他线程偷偷修改，别随便给我做重排序优化，也别把它的值存在寄存器里。这样就能保证buf = p一定在SetEvent之前执行，而且会写入主内存。

方案二：用显式内存屏障 #

如果你不想用volatile，可以在主线程的buf = p之后、SetEvent之前调用WriteReleaseBarrier();，在子线程Wait成功后、访问buf之前调用ReadAcquireBarrier();。不过这种方式不如volatile简洁，还要注意Windows版本的兼容性，一般不推荐除非有特殊需求。

4. 什么时候才需要互斥量？ #

如果你的场景里有多个线程同时写buf指针，或者多个线程同时读写缓冲区里的数据，那你就得用互斥量（比如CreateMutex或者CriticalSection）来保证同一时间只有一个线程操作。但在你现在的简化示例里，只有主线程写buf，子线程等事件后才操作缓冲区，执行顺序是明确的，所以不需要互斥量。

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