智能指针线程安全问题

智能指针是线程安全的吗？（以shared_ptr为例）

概述

      前一阶段面试被别人问到了，第一反应是和普通对象一样，读安全写不安全。其实当时也没有细想，只是当作一个八股文记录下来，其实细细想来，知道其内部原理，发现就迎刃而解了。

先看网上大佬们的结论：boos关于shared_ptr的shared_ptr_thread_safety ，里面提到一些线程不安全的场景的example。也可以参考网上的一些图片好理解 为什么多线程读写 shared_ptr 要加锁？ 由于shared_ptr的操作主要含有两个步骤：复制指针和引用计数加一，所以这两步在多线程中会有问题。所以对于多线程读写shared_ptr结论是：

• 同一个shared_ptr被多线程读，线程安全；
• 同一个shared_ptr被多线程写，不是线程安全；
• 共享引用计数的不同的shared_ptr被多线程写，是线程安全。

引用计数线程安全吗

      但是在shared_ptr中，那个引用计数会存在线程安全问题吗？我们都知道其内部是一个指针加一个计数器，在源码里面，其实临界区就是这两个了。

  template
    class shared_ptr : public __shared_ptr<_Tp>
    {

内部本身没啥变量，看看基类， 基类有两个变量，也就是一个指针，一个引用计数，__shared_ptr_access这个我们先不看，我们先看两个变量。

template
    class __shared_ptr
    : public __shared_ptr_access<_Tp, _Lp>
    {
    public:
      using element_type = typename remove_extent<_Tp>::type;
    ......
     element_type*     _M_ptr;         // Contained pointer.
        __shared_count<_Lp>  _M_refcount;    // Reference counter.
    };

我们可以看到两个变量_M_ptr和_M_refcount，其中可以发现引用计数多了一个宏 _Lp， 这个到底是干嘛的，然后发现是个枚举（话说我也是第一次见到宏为枚举类型，一般不都是typename或者class吗，后续可以发现对同一个函数，根据模板的宏，定义不同的函数实现）如下：

  // Available locking policies:
  // _S_single    single-threaded code that doesn't need to be locked.
  // _S_mutex     multi-threaded code that requires additional support
  //              from gthr.h or abstraction layers in concurrence.h.
  // _S_atomic    multi-threaded code using atomic operations.
  enum _Lock_policy { _S_single, _S_mutex, _S_atomic }; 

  // Compile time constant that indicates prefered locking policy in
  // the current configuration.
  static const _Lock_policy __default_lock_policy = 
#ifdef __GTHREADS
#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
     && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
  _S_atomic;
#else
  _S_mutex;
#endif
#else
  _S_single;
#endif

其中哪些预定义的宏可以通过gcc -E -dM - 查看，看到结果都为1，表明此处默认用的是原子操作。先继续看看这个__shared_count这个类，以及其成员变量_M_pi 的类型是_Sp_counted_base，但是默认new出是一个派生类_Sp_counted_ptr。

  template<_Lock_policy _Lp>
    class __shared_count
    {
      ......
      __shared_count(_Ptr __p) : _M_pi(0)
    {
      __try
        {
          _M_pi = new _Sp_counted_ptr<_Ptr, _Lp>(__p);
        }
    private:
      friend class __weak_count<_Lp>;
      _Sp_counted_base<_Lp>*  _M_pi;
     ......
    };


template
    class _Sp_counted_ptr final : public _Sp_counted_base<_Lp>
    {
    ......
    private:
      _Ptr             _M_ptr;
    };

看来这个_Sp_counted_base是最终的基类，可以看到模板的默认值是__default_lock_policy，上面提到默认值的情况下，是一个原子类型。并且可以看到其一些列操作都是原子操作，所以对于shared_ptr内部的引用计数是线程安全的。

template<_Lock_policy _Lp = __default_lock_policy>
    class _Sp_counted_base
    : public _Mutex_base<_Lp>
    {
    public:
      _Sp_counted_base() noexcept
      : _M_use_count(1), _M_weak_count(1) { }

    void
      _M_add_ref_copy()
      { __gnu_cxx::__atomic_add_dispatch(&_M_use_count, 1); }

      void
      _M_add_ref_lock();
      ·····
  };
template<>
    inline void
    _Sp_counted_base<_S_atomic>::
    _M_add_ref_lock()
    {
      // Perform lock-free add-if-not-zero operation.
      _Atomic_word __count = _M_get_use_count();
      do
    {
      if (__count == 0)
        __throw_bad_weak_ptr();
      // Replace the current counter value with the old value + 1, as
      // long as it's not changed meanwhile.
    }
      while (!__atomic_compare_exchange_n(&_M_use_count, &__count, __count + 1,
                      true, __ATOMIC_ACQ_REL,
                      __ATOMIC_RELAXED));
    }

结论

shared_ptr内部的引用计数是原子的操作，所以是线程安全的。 以上是简单学习了一下，如果问题，还请大佬们指正。

参考

1. shared_ptr_thread_safety
2. 为什么多线程读写 shared_ptr 要加锁？
3. gcc 7.4.0