c - 关键部分中使用的资源是否需要 volatile？

Question

我很好奇volatile对于临界区使用的资源是否必要。假设我有两个线程在两个 CPU 上执行，并且它们在共享资源上竞争。我知道我需要一种锁定机制来确保只有一个线程在该共享资源上执行操作。下面是将在这两个线程上执行的伪代码。

take_lock();

// Read shared resource.
read_shared_resouce();

// Write something to shared resource.
write_shared_resource();

release_lock();

我想知道是否需要使该共享资源易变 以确保当一个线程正在读取共享资源时，该线程不会只是从寄存器中获取值，它实际上会读取来自该共享资源。或者也许我应该使用访问器函数通过一些内存屏障操作易变来访问该共享资源，而不是使该共享资源易变？

Answer 1

I am curious about whether volatile is necessary for the resources used in a critical section. Consider I have two threads executed on two CPUs and they are competing on a shared resource. I know I need to a locking mechanism to make sure only one thread is performing operations on that shared resource.

确保一次只有一个线程访问共享资源只是足以满足此目的的锁定机制的一部分。除其他事项外，这种机制还将确保线程 T_i 在释放锁 L 之前对共享对象执行的所有写入 在随后获得锁 L 之后，所有其他线程 T_j 都可见。就程序的 C 语义而言，尽管存在编译器优化、寄存器使用、CPU 指令重新排序或类似问题。

当使用这样的锁定机制时，volatile 不会提供任何额外的好处来使线程对共享对象的写入对彼此可见。当不使用这种锁定机制时，volatile 不提供完整的替代品。

C 的内置(自 C11 起)互斥体提供了合适的锁定机制，至少在使用 C 的内置线程时是这样。 pthreads 互斥体、Sys V 和 POSIX 信号量，以及各种环境中可用的各种其他类似同步对象也是如此，每个对象都对应于相应的多线程系统。这些语义在类似 C 的多线程实现中非常一致，至少扩展到 Java。当前 (C17) 语言规范的第 5.1.2.4 节描述了 C 的内置多线程的语义要求。

volatile 用于指示可能会在程序的 C 语义范围之外访问对象。这可能会产生以一种被认为是可取的方式与多线程执行交互的属性，但这不是 volatile 的目的或预期用途。如果是，或者如果 volatile 足以满足此类目的，那么我们就不需要 _Atomic 对象和操作。

---

前面的评论侧重于语言级别的语义，这足以回答问题。但是，由于该问题专门询问有关从寄存器访问变量值的问题，我观察到编译器实际上不必在该区域做任何特定于多线程的事情，只要获取和释放锁需要调用函数即可。

特别是，如果函数 f 的执行 E 写入一个对象 o，该对象对其他函数或 f，则 C 实现必须确保在 E 评估任何后续函数调用(例如释放锁所需的)之前，实际在内存上执行了写入。这是必要的，因为写入的值必须对被调用函数的执行可见，而不管任何其他线程。

类似地，如果 E 在函数调用返回后使用 o 的值(例如需要获取锁)，那么它必须从内存中加载该值以确保它看到函数可能执行的任何写入的效果。

在这方面，多线程的唯一特殊之处在于，实现必须确保过程间分析优化或类似操作不会破坏围绕锁定和解锁功能所需的内存读写。实际上，这很少需要特别注意。