weak_ptr 的性能损失是多少？

Question

我目前正在为游戏设计一个对象结构，在我的例子中，最自然的组织变成了一棵树。作为智能指针的忠实粉丝，我专门使用shared_ptr's。然而，在这种情况下，树中的子节点需要访问它的父节点（例如——地图上的生物需要能够访问地图数据——因此他们的父节点的数据。

拥有的方向当然是地图拥有它的存在，因此持有指向它们的共享指针。然而，要从一个存在中访问地图数据，我们需要一个指向父级的指针——智能指针的方式是使用一个引用，即weak_ptr。

然而，我曾经读到锁定 weak_ptr 是一项昂贵的操作——也许这不再是真的了——但考虑到 weak_ptr 会经常被锁定，我担心这种设计注定要表现不佳。

因此问题：

锁定一个weak_ptr 的性能损失是什么？它有多重要？

Answer 1

使用/取消引用 shared_ptr 几乎就像访问原始 ptr 一样，锁定 weak_ptr 与常规指针访问相比是一个性能“繁重”的操作，因为此代码必须是“线程感知的”才能正常工作如果另一个线程触发释放指针引用的对象的情况。至少，它必须执行某种互锁/原子操作，根据定义，这种操作比常规内存访问要慢得多。

像往常一样，查看正在发生的事情的一种方法是inspect generated code：

#include <memory>

class Test
{
public:
    void test();
};

void callFuncShared(std::shared_ptr<Test>& ptr)
{
    if (ptr)
        ptr->test();
}

void callFuncWeak(std::weak_ptr<Test>& ptr)
{
    if (auto p = ptr.lock())
        p->test();
}

void callFuncRaw(Test* ptr)
{
    if (ptr)
        ptr->test();
}

通过 shared_ptr 和原始指针访问是一样的。由于shared_ptr作为引用传递，我们需要加载引用的值，这就是为什么不同之处只是shared_ptr版本的额外加载。

callFuncShared：

callFuncWeak：

通过weak_ptr 调用会产生多出 10 倍的代码，并且充其量只能通过锁定的比较交换，这本身将比取消引用 raw 或 shared_ptr 花费 10 倍以上的 CPU 时间：

只有当共享计数器不为零时，它才能加载指向实际对象的指针并使用它（通过调用对象，或创建shared_ptr）。

Answer 2

对于我自己的项目，我能够通过添加 #define BOOST_DISABLE_THREADS 在任何提升包括之前。 这避免了 weak_ptr::lock 的自旋锁/互斥开销，在我的项目中是 一大瓶颈。由于该项目不是多线程 wrt boost，我可以这样做。

Answer 3

来自 Boost 1.42 源代码（<boost/shared_ptr/weak_ptr.hpp> 第 155 行）：

shared_ptr<T> lock() const // never throws
{
    return shared_ptr<element_type>( *this, boost::detail::sp_nothrow_tag() );
}

所以，James McNellis 的评论是正确的；这是复制构建shared_ptr 的成本。