为什么 std::weak_ptr::expired 被优化掉了？

Question

在下面的代码中，while ( !Ref.expired() ); 被愉快地优化成一个无限循环。如果代码行改为while ( !Ref.lock() );。一切都按预期工作。所以真的有两个问题：

1) 当std::weak_ptr::expired() 访问内存围栏计数器时，编译器如何优化过期？

2) Ref.lock() 真的安全吗，或者这也可以优化掉？

下面的示例代码。

#include <iostream>
#include <memory>
#include <thread>
#include <chrono>

class A
{
public:

    A() 
    { 
        m_SomePtr = std::make_shared<bool>( false );
    }

    virtual ~A()
    {
        std::weak_ptr<bool> Ref = m_SomePtr;
        m_SomePtr.reset();

        // Spin (will be optimised into an infinite loop in release builds)
        while ( !Ref.expired() );
    }

    std::shared_ptr<bool> GetPtr() const { return m_SomePtr; }

private:
    std::shared_ptr<bool> m_SomePtr;
};

class B
{
public:
    B( std::shared_ptr<bool> SomePtr ) : m_Ref( SomePtr ) {}

    void LockPtr() { m_SomePtr = m_Ref.lock(); }
    void UnLockPtr() { m_SomePtr.reset(); }

private:
    std::shared_ptr<bool> m_SomePtr;
    std::weak_ptr<bool> m_Ref;
};

int main()
{
    std::unique_ptr<A> a( new A() );
    std::unique_ptr<B> b( new B( a->GetPtr() ) );

    b->LockPtr();

    std::cout << "Starting " << std::endl;

    std::thread first( [&]()
    {
        std::this_thread::sleep_for( std::chrono::seconds( 5 ) );
        b->UnLockPtr();
    } );

    std::thread second( [&]()
    {
        a.reset( nullptr );
    } );

    first.join();
    second.join();

    std::cout << "Complete" << std::endl;
    return 0;
}

Answer 1

您的程序不正确；共享所有权指针工具不打算用于同步。

[intro.multithread]/24：

实现可能假设任何线程最终都会执行以下操作之一：
— 终止，
— 调用库 I/O 函数，
— 访问或修改 volatile 对象，或
— 执行同步操作或原子操作。

std::weak_ptr::expired() 不是同步操作或原子操作；该标准所说的只是它没有引入数据竞争。由于对Library defect 2316、std::weak_ptr::lock() 的解析被认为是原子操作，因此回答2）您使用Ref.lock() 的代码自C++14 起有效。

现在，确实，如果您要尝试使用语言和库工具创建自己的库实现 weak_ptr，它必然会使用同步和/或原子操作工具，因此用户提供的 @987654326 @ 可以继续运行（根据 [intro.multithread]/2 和 /25，实现必须确保线程最终取得进展）。但实现没有义务将其自己的库限制为语言和库设施。

我不完全确定编译器如何优化对expired() 的访问。我猜 MSVC 库正在利用 x86 内存模型的某些方面，编译器/优化器观察到的 C++ 内存模型无法保证。