c ++仔细检查是否带有锁的语句优化

Question

我的问题不是关于双重检查锁定，而是类似的。
在下面的代码中，编译器是否可以优化出内部的if语句？

无效 MyClass:foo() { if(x) //MyClass的成员数据定义为bool { loc.lock(); //互斥体。超出范围时解锁 if(x) //编译器可以优化这个吗？ { fire1();//doSomthingNotAffectingX } } }

X 通过同一翻译单元中的另一个线程设置。

无效 MyClass::unset() { loc.lock(); x=假； 火2（）； }

这个想法是保证如果调用了fire2，就不能调用fire1

Answer 1

在我的回答中，我假设您使用的是 std::mutex 而不是您自己的自定义类！

本质上，编译器无法优化第二个if。

好吧，如果编译器能够以某种方式确定x 不能（合法地）更改，它可能会删除检查，但显然，这里不是这种情况。只有当生成的程序运行AS-IF时，编译器才能进行优化。

在 C++ 11 及更高版本中，互斥体是障碍。因此，如果变量受到互斥锁的适当保护，您将读取预期值。但是，如果您忘记在适当的位置放置一些互斥锁，那么行为将是未定义的。

在这里，由于您的第一次检查是读取，您可能会遇到问题，如果 x 在被设置为 false 后可以再次变为 true。

Memory model

C++11 introduced a standardized memory model. What does it mean? And how is it going to affect C++ programming?

我强烈推荐阅读 Anthony Williams 的书 C++ Concurrency in Action，实用多线程。这将有助于理解现代 C++ 多线程。

在您的代码中，您是否需要通过互斥锁保护 fire1 和 fire2？ 如果该函数还等待 mutex，则调用该函数可能会很危险，因为它可能导致僵局。此外，lock 的有效时间可能比要求的要长。如果您只需要确保在调用fire2 时不调用fire1，那么std::atomic<bool> 就足够了……

-- 编辑--

最后，文档中有一个很好的例子：std::mutex

-- 编辑#2--

正如评论中所指出的，我的回答对于一般情况并不完全有效。我确实认为上面的代码可以与bool 一起正常工作，前提是它只能从true 更改为false。

于是我在网上搜索了一下，找到了那些文章：

• Double-Checked Locking is Fixed In C++11
• Double-checked locking: Why doesn’t it work and how to fix it

Answer 2

如果编译器不知道除loc.lock() 之外的其他人可能会更改x，并且它知道loc.lock() 肯定不会更改x，那么它可以假设x 不会在两者之间更改ifs。在这种情况下，可能会将x 存储在寄存器中，或者完全省略if。

如果你想避免这种不安全的优化，你必须让编译器知道。在 C++11 上，使用 std::atomic<bool>。在早期版本中，将其设为volatile bool。两者都不做，编译器可能会破坏你的代码。