确定 std::shared_ptr 是否是对对象的唯一引用答案

【问题标题】：determine if a std::shared_ptr is the unique reference to an object确定 std::shared_ptr 是否是对对象的唯一引用
【发布时间】：2019-02-02 10:30:17
【问题描述】：

有没有办法确保std::shared_ptr 是整个程序中对一个对象的唯一引用？

我的印象是，即使在多线程环境中，以下内容也足够了，但由于 std::shared_ptr::unique 已被弃用，我不太确定（我的并发功能让我失望了）：

std::shared_ptr<Foo> bar(std::shared_ptr<Foo>&& src) {
     std::shared_ptr<Foo> self = std::move(src);
     if(self && self.unique()) {
        // self is *the* only reference
     }

     return std::move(self);
}

（编辑）

如果我理解正确（参见 eg Why is std::shared_ptr::unique() deprecated?），原子引用计数保证 self 是 if 块内数据的唯一实时引用，但通过破坏进行修改引用不是在调用unique() 之前排序，并且可能尚未完成。

从今以后，在 if 块内修改 *self 时仍然存在潜在的数据竞争。这是正确的吗？

【问题讨论】：

为什么不使用std::unique_ptr 来确保这一点？
unique() 遭受检查可能在您使用它时失效。您可以得到一个很好的猜测，但要确保它是独一无二的，您必须声明唯一的所有权并在实际尝试后检查是否成功。我不确定shared_ptr 是否支持。
@molbdnilo，您可以使用原始指针绕过智能指针信任模型，但这样做只会伤害自己。我认为在您不会特意避开它们的假设下提供所有权保证是合理的。
@chris 当然很痛，但问题是它是否可以变得不可能。而且 C++ 的类型系统太原始了。
@molbdnilo，我想我在阅读这个问题时比理论上更实用。

标签： c++ multithreading shared-ptr rvalue-reference

【解决方案1】：

这还不够，因为.unique()（和.use_count()）会忽略与您的shared_ptr 相关联的任何weak_ptrs，这可能是.lock()ed，从而使您的假设无效。

【讨论】：

我明白了。但是假设这是一个内部数据结构，我可以保证周围没有weak_ptr。
那么没关系，假设没有其他线程试图复制它。