为什么不推荐使用 std::shared_ptr::unique() ？

Question

std::shared_ptr::unique() 的技术问题是什么，导致它在 C++17 中被弃用？

根据cppreference.com，std::shared_ptr::unique() 在 C++17 中被弃用为

从 C++17 开始不推荐使用此函数，因为 use_count 只是多线程环境中的近似值。

我理解这对于use_count() > 1 是正确的：当我持有对它的引用时，其他人可能同时放开他的或创建一个新副本。

但是如果 use_count() 返回 1（这是我在调用 unique() 时感兴趣的内容），那么没有其他线程可以以一种活泼的方式更改该值，所以我希望这应该是安全的：

if (myPtr && myPtr.unique()) {
    //Modify *myPtr
}

我自己搜索的结果：

我找到了这个文档：http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0521r0.html，它提议弃用以响应 C++17 CD 评论 CA 14，但我找不到该评论本身。

作为替代方案，该论文建议添加一些注释，包括以下内容：

注意：当多个线程可以影响use_count()的返回值时，应将结果视为近似值。 特别是，use_count() == 1 并不意味着通过先前销毁的shared_ptr 的访问在任何意义上都已完成。 — 结束说明

我知道当前指定 use_count() 的方式可能就是这种情况（由于缺乏保证同步），但为什么解决方案不只是指定此类同步并因此使上述模式安全？如果存在不允许此类同步的基本限制（或使其代价高昂），那么如何正确实现析构函数？

更新：

我忽略了@alexeykuzmin0 和@rubenvb 提出的明显案例，因为到目前为止，我只在其他线程本身无法访问的shared_ptr 实例上使用了unique()。因此，该特定实例不会以不正当的方式被复制。

我仍然有兴趣了解 CA 14 到底是什么，因为我相信我的所有 unique() 用例只要保证与其他 shared_ptr 不同实例发生的任何情况同步就可以工作线程。所以它对我来说似乎仍然是一个有用的工具，但我可能会在这里忽略一些基本的东西。

为了说明我的想法，请考虑以下内容：

class MemoryCache {
public:
    MemoryCache(size_t size)
        : _cache(size)
    {
        for (auto& ptr : _cache) {
            ptr = std::make_shared<std::array<uint8_t, 256>>();
        }
    }

    // the returned chunk of memory might be passed to a different thread(s),
    // but the function is never accessed from two threads at the same time
    std::shared_ptr<std::array<uint8_t,256>> getChunk()
    {
        auto it = std::find_if(_cache.begin(), _cache.end(), [](auto& ptr) { return ptr.unique(); });
        if (it != _cache.end()) {
            //memory is no longer used by previous user, so it can be given to someone else
            return *it;
        } else {
            return{};
        }
    }
private:
    std::vector<std::shared_ptr<std::array<uint8_t, 256>>> _cache;
};

这有什么问题吗（如果unique()实际上会与其他副本的析构函数同步）？

Answer 1

考虑以下代码：

// global variable
std::shared_ptr<int> s = std::make_shared<int>();

// thread 1
if (s && s.unique()) {
    // modify *s
}

// thread 2
auto s2 = s;

这里我们有一个经典的竞争条件：s2 可能（也可能不会）在线程 2 中创建为 s 的副本，而线程 1 在 if 中。

unique() == true 意味着没有人拥有指向同一内存的shared_ptr，但并不意味着任何其他线程无法直接或通过指针或引用访问初始shared_ptr。

Answer 2

我认为P0521R0 通过滥用shared_ptr 作为线程间同步来解决潜在数据竞争。 它说use_count()返回不可靠的引用计数值，因此，unique()成员函数在多线程时将无用。

int main() {
  int result = 0;
  auto sp1 = std::make_shared<int>(0);  // refcount: 1

  // Start another thread
  std::thread another_thread([&result, sp2 = sp1]{  // refcount: 1 -> 2
    result = 42;  // [W] store to result
    // [D] expire sp2 scope, and refcount: 2 -> 1
  });

  // Do multithreading stuff:
  //   Other threads may concurrently increment/decrement refcounf.

  if (sp1.unique()) {      // [U] refcount == 1?
    assert(result == 42);  // [R] read from result
    // This [R] read action cause data race w.r.t [W] write action.
  }

  another_thread.join();
  // Side note: thread termination and join() member function
  // have happens-before relationship, so [W] happens-before [R]
  // and there is no data race on following read action.
  assert(result == 42);
}

成员函数unique() 没有任何同步效果，并且[D] shared_ptr 的析构函数与[U] 调用unique() 之间没有happens-before 关系。 所以我们不能期望关系 [W] ⇒ [D] ⇒ [U] ⇒ [R] 和 [W] ⇒ [R]。 （'⇒' 表示发生前的关系）。

---

已编辑：我发现了两个相关的 LWG 问题； LWG2434. shared_ptr::use_count() is efficient，LWG2776. shared_ptr unique() and use_count()。这只是一种推测，但 WG21 委员会优先考虑 C++ 标准库的现有实现，因此他们将其行为编码在 C++1z 中。

LWG2434 引用（强调我的）：

shared_ptr 和weak_ptr 注意到他们的use_count() 可能效率低下。 这是对重新链接实现的一种尝试（例如，可以由 Loki 智能指针使用）。 但是，没有任何shared_ptr 实现使用重新链接，尤其是在 C++11 认识到多线程的存在之后。每个人都使用原子引用计数，所以 use_count() 只是一个原子负载。

LWG2776 引用（强调我的）：

LWG 2434 删除了 shared_ptr 中 use_count() 和 unique() 的“仅调试”限制引入了一个错误。为了使unique() 产生有用且可靠的值，它需要一个同步子句来确保通过另一个引用的先前访问对于unique() 的成功调用者是可见的。 许多当前的实现使用宽松的负载，并且不提供此保证，因为它没有在标准中说明。对于调试/提示使用没问题。没有它，规范就不清楚并且可能具有误导性。

[...]

我更愿意将use_count() 指定为仅提供实际计数的不可靠提示（另一种表示仅调试的方式）。或者像 JF 建议的那样弃用它。 如果不增加更多的围栏，我们就无法使use_count() 可靠。我们真的不希望有人等待use_count() == 2 来确定另一个线程已经走了那么远。不幸的是，我认为我们目前没有说任何话来明确这是一个错误。

这意味着use_count() 通常使用memory_order_relaxed，并且根据use_count() 既没有指定也没有实现唯一性。

Answer 3

为了您的观赏乐趣：http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf

本文档包含 Issaquah 会议的所有 NB（国家机构）cmets。 CA 14 内容如下：

删除了 use_count() 的“仅调试”限制和 shared_ptr 中的 unique() 引入了一个错误：为了使 unique() 能够 产生一个有用和可靠的值，它需要一个同步子句来 确保通过另一个引用的先前访问是可见的 unique() 的成功调用者。许多当前的实现使用 宽松的负载，并且不提供此保证，因为它没有说明 在标准。对于调试/提示使用没问题。没有它 规范不明确且具有误导性。

Answer 4

std::enable_shared_from_this 的存在是制造任何麻烦的麻烦制造者 unique() 的有趣用法。事实上，std::enable_shared_from_this 允许从任何线程的原始指针创建一个新的shared_ptr。这意味着unique() 永远不能保证任何事情。

但是考虑另一个库...虽然这与shared_ptr 无关，但在Qt 中有一个名为isDetached() 的内部 方法，其实现（几乎）与unique() 相同。 它用于一些非常有用的优化目的：当true 时，指向的对象可以在不执行“写时复制”操作的情况下发生变异。 事实上，托管资源一旦唯一，就不能被来自另一个线程的操作共享。如果 enable_shared_from_this 不存在，则 shared_ptr 可能会出现相同的模式。

这就是恕我直言，unique() 已从 C++20 中删除的原因：具有误导性。