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功能，
   - 访问或修改易失性对象，或
   - 执行同步操作或原子操作。

std::weak_ptr::expired()不是同步操作或原子操作;标准所说的是它没有引入数据竞争。由于Library defect 2316的解析，std::weak_ptr::lock()被认为是原子操作，所以回答2）使用Ref.lock()的代码从C ++ 14开始有效。

现在，如果您尝试使用语言和库设施创建自己的weak_ptr库实现，那么它必然会使用同步和/或原子操作工具，所以用户提供的weak_ptr::expired()可以旋转（实现将有义务确保线程最终取得进展，每 [intro.multithread] / 2和/ 25）。但是实现没有义务将自己的库限制为语言和库设施。

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

为什么std :: weak_ptr :: expired已经优化了？

1 个答案: