shared_ptr是线程安全的吗？
时间：2021-08-19 15:30:18
[导读]来源|https://blog.csdn.net/Solstice/article/details/8547547声明| 本文为CSDN博主[陈硕]原创文章，如有侵权请联系删除最近看见交流群里小伙伴在讨论这个问题，自己也很感兴趣，上网找到了陈硕大佬的这篇文章，分享给大家！以下是正...
来源 | https://blog.csdn.net/Solstice/article/details/8547547声明 | 本文为CSDN博主[陈硕]原创文章，如有侵权请联系删除
一个 shared_ptr 对象实体可被多个线程同时读取（文档例1）；
两个 shared_ptr 对象实体可以被两个线程同时写入（例2），“析构”算写操作；
如果要从多个线程读写同一个 shared_ptr 对象，那么需要加锁（例3~5）。
请注意，以上是 shared_ptr 对象本身的线程安全级别，不是它管理的对象的线程安全级别。
后文（p.18）则介绍如何高效地加锁解锁。本文则具体分析一下为什么“因为 shared_ptr 有两个数据成员，读写操作不能原子化”使得多线程读写同一个 shared_ptr 对象需要加锁。这个在我看来显而易见的结论似乎也有人抱有疑问，那将导致灾难性的后果，值得我写这篇文章。本文以 boost::shared_ptr 为例，与 std::shared_ptr 可能略有区别。
shared_ptr 的数据结构
shared_ptr 是引用计数型（reference counting）智能指针，几乎所有的实现都采用在堆（heap）上放个计数值（count）的办法（除此之外理论上还有用循环链表的办法，不过没有实例）。具体来说，shared_ptr 包含两个成员，一个是指向 Foo 的指针 ptr，另一个是 ref_count 指针（其类型不一定是原始指针，有可能是 class 类型，但不影响这里的讨论），指向堆上的 ref_count 对象。ref_count 对象有多个成员，具体的数据结构如图 1 所示，其中 deleter 和 allocator 是可选的。
图 1：shared_ptr 的数据结构
为了简化并突出重点，后文只画出 use_count 的值：
以上是 shared_ptr x(new Foo); 对应的内存数据结构。
如果再执行 shared_ptr y = x; 那么对应的数据结构如下。
但是 y=x 涉及两个成员的复制，这两步拷贝不会同时（原子）发生。
中间步骤 1，复制 ptr 指针：
中间步骤 2，复制 ref_count 指针，导致引用计数加 1：
步骤1和步骤2的先后顺序跟实现相关（因此步骤 2 里没有画出 y.ptr 的指向），我见过的都是先1后2。
既然 y=x 有两个步骤，如果没有 mutex 保护，那么在多线程里就有 race condition。
多线程无保护读写 shared_ptr 可能出现的 race condition考虑一个简单的场景，有 3 个 shared_ptr 对象 x、g、n：
shared_ptr g(new Foo); // 线程之间共享的 shared_ptr shared_ptr x; // 线程 A 的局部变量 shared_ptr n(new Foo); // 线程 B 的局部变量 一开始，各安其事。
线程 A 执行 x = g; （即 read g），以下完成了步骤 1，还没来及执行步骤 2。这时切换到了 B 线程。
同时编程 B 执行 g = n; （即 write g），两个步骤一起完成了。
先是步骤 1：
再是步骤 2：
这是 Foo1 对象已经销毁，x.ptr 成了空悬指针！
最后回到线程 A，完成步骤 2：
多线程无保护地读写 g，造成了“x 是空悬指针”的后果。这正是多线程读写同一个 shared_ptr 必须加锁的原因。
当然，race condition 远不止这一种，其他线程交织（interweaving）有可能会造成其他错误。
思考，假如 shared_ptr 的 operator= 实现是先复制 ref_count（步骤 2）再复制 ptr（步骤 1），会有哪些 race condition？
杂项
shared_ptr 作为 unordered_map 的 key
如果把 boost::shared_ptr 放到 unordered_set 中，或者用于 unordered_map 的 key，那么要小心 hash table 退化为链表。http://stackoverflow.com/questions/6404765/c-shared-ptr-as-unordered-sets-key/12122314#12122314
直到 Boost 1.47.0 发布之前，unordered_set > 虽然可以编译通过，但是其 hash_value 是 shared_ptr 隐式转换为 bool 的结果。也就是说，如果不自定义hash函数，那么 unordered_{set/map} 会退化为链表。https://svn.boost.org/trac/boost/ticket/5216
Boost 1.51 在 boost/functional/hash/extensions.hpp 中增加了有关重载，现在只要包含这个头文件就能安全高效地使用 unordered_set 了。
这也是 muduo 的 examples/idleconnection 示例要自己定义 hash_value(const boost::shared_ptr
一个 shared_ptr 对象实体可被多个线程同时读取（文档例1）；
两个 shared_ptr 对象实体可以被两个线程同时写入（例2），“析构”算写操作；
如果要从多个线程读写同一个 shared_ptr 对象，那么需要加锁（例3~5）。
请注意，以上是 shared_ptr 对象本身的线程安全级别，不是它管理的对象的线程安全级别。
后文（p.18）则介绍如何高效地加锁解锁。本文则具体分析一下为什么“因为 shared_ptr 有两个数据成员，读写操作不能原子化”使得多线程读写同一个 shared_ptr 对象需要加锁。这个在我看来显而易见的结论似乎也有人抱有疑问，那将导致灾难性的后果，值得我写这篇文章。本文以 boost::shared_ptr 为例，与 std::shared_ptr 可能略有区别。
shared_ptr 的数据结构
shared_ptr 是引用计数型（reference counting）智能指针，几乎所有的实现都采用在堆（heap）上放个计数值（count）的办法（除此之外理论上还有用循环链表的办法，不过没有实例）。具体来说，shared_ptr
图 1：shared_ptr 的数据结构
为了简化并突出重点，后文只画出 use_count 的值：
以上是 shared_ptr
如果再执行 shared_ptr
但是 y=x 涉及两个成员的复制，这两步拷贝不会同时（原子）发生。
中间步骤 1，复制 ptr 指针：
中间步骤 2，复制 ref_count 指针，导致引用计数加 1：
步骤1和步骤2的先后顺序跟实现相关（因此步骤 2 里没有画出 y.ptr 的指向），我见过的都是先1后2。
既然 y=x 有两个步骤，如果没有 mutex 保护，那么在多线程里就有 race condition。
多线程无保护读写 shared_ptr 可能出现的 race condition考虑一个简单的场景，有 3 个 shared_ptr
shared_ptr
线程 A 执行 x = g; （即 read g），以下完成了步骤 1，还没来及执行步骤 2。这时切换到了 B 线程。
同时编程 B 执行 g = n; （即 write g），两个步骤一起完成了。
先是步骤 1：
再是步骤 2：
这是 Foo1 对象已经销毁，x.ptr 成了空悬指针！
最后回到线程 A，完成步骤 2：
多线程无保护地读写 g，造成了“x 是空悬指针”的后果。这正是多线程读写同一个 shared_ptr 必须加锁的原因。
当然，race condition 远不止这一种，其他线程交织（interweaving）有可能会造成其他错误。
思考，假如 shared_ptr 的 operator= 实现是先复制 ref_count（步骤 2）再复制 ptr（步骤 1），会有哪些 race condition？
杂项
shared_ptr 作为 unordered_map 的 key
如果把 boost::shared_ptr 放到 unordered_set 中，或者用于 unordered_map 的 key，那么要小心 hash table 退化为链表。http://stackoverflow.com/questions/6404765/c-shared-ptr-as-unordered-sets-key/12122314#12122314
直到 Boost 1.47.0 发布之前，unordered_set
Boost 1.51 在 boost/functional/hash/extensions.hpp 中增加了有关重载，现在只要包含这个头文件就能安全高效地使用 unordered_set
这也是 muduo 的 examples/idleconnection 示例要自己定义 hash_value(const boost::shared_ptr
下载文档
