假设我有自己的非内联函数 LockMutex 和 UnlockMutex，它们在内部使用了一些适当的互斥锁 - 例如 boost。编译器如何知道不对 LockMutex 和 UnlockMutex 调用的其他操作重新排序？它不可能知道我将如何在其他编译单元中实现这些功能。
void SomeClass::store(int i)
{
LockMutex(_m);
_field = i; // could the compiler move this around?
UnlockMutex(_m);
}
ps：应该使用类的实例来持有锁以保证解锁。为了简化示例，我省略了这一点。
【问题讨论】：
标签： c++ compiler-optimization memory-barriers
它不可能知道我将如何在其他编译单元中实现这些功能。
这是关键 - 因为编译器（通常）不知道函数调用的实现，所以它不能将存储移动到这些函数调用之外的_field。
一般来说，由于_field 可以在SomeClass::store() 之外访问（它不是本地的），编译器无法知道它是否被外部函数修改，因此它必须执行存储到_field 之间函数调用顺序点。
底层硬件平台可能需要注意内存屏障或缓存刷新的形式，以处理硬件中发生的缓存或乱序操作。如有必要，互斥 API 的平台实现将处理这些问题。
【讨论】：
一般来说，编译器不会移动代码，除非它确定这样做不会影响运行时行为。
【讨论】：
正如它所写的，如果函数不是内联的，编译器不会移动变量赋值，因为调用可能与 _field 变量无关，但它必须保持调用的严格顺序。但是，如果编译器决定内联调用，我认为它会将它们视为独立代码块，也就是说，它只会重新排序同一代码单元（内联函数本身）内的指令，而不是以下或前面的代码（对 _field 变量的赋值）。
【讨论】：
您是对的，该代码是正确且安全的。不过，我确实想到了一个“代码笑话”。
pthread_mutex_lock( &mx ) + foo() + pthread_mutex_unlock( &mx );
【讨论】：
如果编译器这样做，那将是一个糟糕的编译器。 ;-)
【讨论】：
如果编译器不能保证函数调用不会产生会在调用之间修改变量的副作用，它就不能移动代码。如果该变量是一个局部变量并且您从未获取过引用或创建指向它的指针，编译器可能会认为它可以安全移动；我不知道。
【讨论】：