boost::shared_ptr 分析与实现

boost::shared_ptr 分析与实现、

boost::shared_ptr 分析与实现

/************************************************************
* file: shared_ptr
* 
* desc: 本文将对boost::shared_ptr作一详细的介绍。 本文介绍的不是用法，而是
* 智能指针的原理，结构以及boost对其的实现. 最后还会给出一个简化了的实现。
* 
* author: whiteear
* date: 2007-05-10
* copyright: 任意发布
***********************************************************/


shared_ptr

1 boost 介绍

关于boost的介绍， 网上一大堆。 google一下就行。 作为初学者， 也没有能力去全面介绍它。

2 shared_ptr 介绍

在boost库中， 智能指针并不只shared_ptr一个。同族但有不同的功能目标的还有如下5个：
scoped_ptr
scoped_array
shared_ptr
shared_array
weak_ptr

前面两个， 与标准C++中的智能指针auto_ptr功能基本类似， 不过它不传递所有权， 不可复制。
从其名称就可以看出， 其主要目标就是在小范围， 小作用域中使用，以减少显式的delete, new配对操作，
提高代码的安全性。scoped_ptr是针对指针的版本， 而scoped_array同是专门针对数组的。（记住， 删除
一个指针使用delete p; 而删除一个数组使用delete[] p);

后面两个是本文的重点，它们在所有对象中， 共享所指向实体的所有权。 即只要是指向同一个实体
对象的shared_ptr对象， 都有权操作这个对象，并根据自己产生新的对象，并把所有权共享给新的对象。即它
是满足STL对对象的基本要求可复制，可赋值的。可以与所有的STL容器，算法结合使用。顾名思义， shared_ptr
是针对任意类型的指针的， 而shared_array则是专门针对任意类型的数组的。

最后一个weak_ptr。

3 shared_ptr 分析

3.1 一些思考

C++对内存数据的直接可操作性以及指针的使用，给编程带来了极大的灵活， 
但同时也还来了很大的问题。 程序在运行时，如果出现segment fault, 
大部分原因在于非法访问了内存。 
或者访问了一个越界的地址，或者访问了一个已经失效的指针。我们可以随时、随地的NEW一个对象， 并把它赋值给某个指针。 
在以后随时要吧通过此指针访问这个对象。 
但问题时NEW出来的对象在内存的堆空间中，并不是函数调用栈中，也就是说一个New出来的对象，从生命期上来说， 
是全局的， 只要不Delete， 它就一直存在。 相对的实际的内存是有限的， 
我们不能只索取而不释放， 否则终有一刻会内存耗尽，New不出新对象。

问题1： 什么时候释放？
New很简单， Delete也很简单。 一个New配对一个Delete也很简单。但不简单的就是什么时候New， 什么时候Delete。New还好办些， 
有需求的时候就可以New， 那什么时候一个New出来的对象不再有用呢？什么时候它该被Delete呢？ 
对于这个问题， Java采用的时GC的机制，由虚拟机通过一定的算法实现。 
但Java的GC机制被人诟病也不是一天两天了。 它太慢，太吃内存了。 
C++因为各种各样的原因而没有采用GC， 把这个问题直接丢给了程序员。

问题2： 资源申请即初始化
在C++之父Bjarne Stroustrup老大的巨著《The C++ Programming Language》第14章， 
第4节资源管理介绍了“资源申请即初始化”。 利用局部对象管理资源的技术通常被说成是“资源申请即初始化”。 
这种技术依赖于构造函数和析构函数的特性， 以及它们与异常机制的关系。 

我们知道， 一个对象在超出它的作用域时， 会自动被析构。 那么我们就可以设想， 可不可以将New
出来的对象，托管给另一个对象，让它自动的在超出作用域时， 去释放New出来的对象。 这样我们就可以
高枕无忧的去New， 释放的时机就转嫁给托管对象（事实上转嫁给了编译器，因为它知道什么时候这个对
象超出作用域）。

问题3： 托管的资源
当一个New出来的资源被托管之后， 我们所有针对此资源的操作就应该通过这个代理商来进行。当然我
们也可以绕过这个代理商直接与资源对话。这时候我们是不是又回归到了原始的那种状态， 在得到一部分
灵活性， 直接性的同时， 也失去了代理商所具有的管理功能。

事实上， 考查一下C++的指针就会知道， 指针本身也是一个代理商。 只不过它是效率最高的代理商（也许
是资源厂商自己设置的一级代码吧，  )。 通过指针我们可以间接的访问它所指代的实体对象。 通过*(dereference)
操作可以得到实体， 通过->可以直接访问实体的内容。 抽象这些特征（类似于STL中Iterator的概念）， 
我们的新的代理也应该具有这样的功能。 

问题4： 释放时机的确定
通过回答上面3个问题。我们似乎已经解决了所有的问题。 
我们得到了一个代理， 将我们的资源托管给它。通过代理我们以熟悉的方式访问， 
操作资源。在合适的时候代理自动帮助我们释放掉不再使用的资源。 一切都很美好！！！

类似下面的代码应该可以很好的工作：
work()
{
resource r = new resource();
proxy p(r);
// use p to do something
}

当work被执行完成时， 资源r自动被p释放掉。 我们得到的益处好象并不多， 
只是少写了几个delete语句。 
考虑一下，r是在堆栈中的，所以它的生命期是比较长的， 
我们如果想在work之外使用r呢？ 如果同时有多个p的复本时呢？ 
在那一个p被析构时真正的释放这个唯一的资源呢？

考虑一下现实生活中， 一个资源厂商通常会有多家代理， 
任意一家代理都可以处理这个资源。 考虑一下， 
如果没有任何一个代理愿意去代理这个资源厂商的资源，是不是表明这个资源并不被市场所接收，即它是无用的，应该被淘汰的。 
这个时候厂商就应该去相关部门申请耍破产了。

我们的代理也应该这样，它自动的统计有多少个对当前资源的代理， 
当没有代理去托管这个资源时， 就应该释放这个资源（delete)。

问题5： 同步
现在多线程编程已经非常普遍， 大家都喜欢一心二用， 三用， 甚至N用。 
如果采用上面4个问题的回答来解决资源管理的问题。那么对第4个问题的回答就还缺少点。 

当我们使用一个记数器去记录当前对此资源的代理有多少个时， 
这个记数器本身是不是也成为一个关键性的资源！！！ 
对记数器的操作特别是有新代理加入或某个代理析构时， 都要对记数进行修改。 
随着多线程的加入，就必须要保证记数器值在所有的代理中都是一样的， 是同步的。 否则后果真是难以想象。

因此在我们的代理设计中， 必须要对记数器部分作线程同步。


3.2 boost::shared_ptr的解决方案


上面我们分析了shared_ptr问题的产生，以及可能的实现方式和应该注意的问题。 下面我们来看看boost::shared_ptr是如何实现上面的思想的。

3.2.1 文件结构
定义boost::shared_ptr主要涉及到以下文件

shared_ptr.hpp
  detail/shared_count.hpp
  detail/sp_counted_base.hpp
  detail/sp_counted_base_pt.hpp
  detail/sp_counted_base_win32.hpp
  detail/sp_counted_base_nt.hpp
  detail/sp_counted_base_pt.hpp
  detail/sp_counted_base_gcc_x86.hpp
  ...    
  detail/sp_counted_base_impl.hpp

涉及的类主要有以下几个：
shared_ptr
shared_count
sp_counted_base
sp_counted_base_impl 

其中
shared_ptr定义在shared_ptr.hpp中
share_count定义在shared_count.hpp中
sp_counted_base定义在sp_counted_base_XXX.hpp中。 
XXX指代针对特定平台的实现。
sp_counted_base_impl定义在sp_counted_base_impl.hpp中

3.2.2 类功能
sp_counted_base 是问题4中， 记数器的实现。 
针对不同的平台使用了不同的同步机制。 如pt是针对linux, unix平台使用pthread接口进行同步的。 
win32是针对windows平台， 使用InterlockedIncrement， InterlockedDecrement机制。 
gcc_x86是针对AMD64硬件平台的， 内部使用汇编指令实现了atomic_increment, 
atomic_decrement。 

sp_counted_base_impl 是个模板， 它继承自sp_counted_base, 
主要实现了父类中一个纯虚函数dispose。具体的由它来负责在记数值到0（即没有代理时）释放所托管的资源。

shared_count是个类模板。它存在的意义在于和代理类shared_ptr同生共死， 
在构造函数中生成记数器，在代理的传递过程中驱动记数器增减。
shared_ptr是个类模板。 它是托管资源的代理类， 所有对资源的操作， 
访问都通过它来完成。

下图展示了它们之间的相互关系

figure01 shared_ptr.jpeg


3.2.3 类详细介绍

shared_ptr 类模板。 它是我们直接使用的代理类。 
两个属性
pn : shared_count 记数器类。 shared_ptr完全操作pn的生命期， 
在构造时构造它，在析构时自动析构它。 
这些都是利用构造与析构函数的特性自动完成的。

template
explicit shared_ptr( Y * p ): px( p ), pn( p ) // Y must be 
complete
{
detail::sp_enable_shared_from_this( pn, p, p );
}

px : T* 它是代理的资源的指针。 所有针对资源的操作*, 
->都直接使用它来完成。

reference operator* () const // never throws
{
BOOST_ASSERT(px != 0);
return *px;
}

T * operator-> () const // never throws
{
BOOST_ASSERT(px != 0);
return px;
}


两个方法：
operator= 完成代理的赋值传递。 
通过这样，就可以有多个代理同时托管同一个资源。在众多的代理中， 它们共享所托管资源的操作权。

shared_ptr & operator=(shared_ptr const & r) // never throws
{
px = r.px;
pn = r.pn; // shared_count::op= doesn't throw
return *this;
} 

T* get() 资源原始位置的获取。通过这个方法，我们可以直接访问到资源， 
并可以对它进行操作。

T * get() const // never throws
{
return px;
}

user_count 返回当前资源的代理个数，即有多少个对些资源的引用。

long use_count() const // never throws
{
return pn.use_count();
}


为了方便操作，并完全模拟原生指针的行为，boost::shared_ptr还定义了大量的其它操作函数。


shared_count类 记数器的包装。
一个属性：
pi : sp_counted_base * 它指向真正的记数器。

构造函数：
template explicit shared_count( Y * p ): pi_( 0 )
#if defined(BOOST_SP_ENABLE_DEBUG_HOOKS)
, id_(shared_count_id)
#endif
{
#ifndef BOOST_NO_EXCEPTIONS

try
{
pi_ = new sp_counted_impl_p( p );
}
catch(...)
{
boost::checked_delete( p );
throw;
}

#else

pi_ = new sp_counted_impl_p( p );

if( pi_ == 0 )
{
boost::checked_delete( p );
boost::throw_exception( std::bad_alloc() );
}

#endif
}


当使用一个资源指针来构造一个shared_count时，它知道针对此资源要生成一个代理。 
所以生成一个记数器pi。如果在构造记数器的过程中出现任何异常行为，即记数器资源的初始化未成功完成时， 就释放掉资源。 
（这就是资源申请即初始化， 对于一个资源管理类来说，要不所有资源申请成功， 要不构造失败）

operator= 赋值函数。 
在shared_ptr被赋值的时候，会调用它。经过复制后一个shared_ptr变成两个， 所以要对记数器进行增加。 
同时如果被赋值的代理原有托管的资源将被释放。

shared_count & operator= (shared_count const & r) // nothrow
{
sp_counted_base * tmp = r.pi_;

if( tmp != pi_ )
{
if( tmp != 0 ) tmp->add_ref_copy();
if( pi_ != 0 ) pi_->release();
pi_ = tmp;
}

return *this;
}

析构函数 析构函数在shared_ptr超出作用域被析构时自动调用。 
每析构一个shared_ptr,则代理数就少一个， 所以调用记数器的release函数， 
减少记数值。

~shared_count() // nothrow
{
if( pi_ != 0 ) pi_->release();
#if defined(BOOST_SP_ENABLE_DEBUG_HOOKS)
id_ = 0;
#endif
}

sp_counted_base 记数器类。 
这是一个普通类，没有被模板化。它定义了记数器公用的所有操作， 并实现了同步。

两个属性
use_count 记录当前的代理数目。
mutex 互斥锁（在不同平台的实现中，是不同的类型。以linux为例， 
是pthread_mutex_t)


构造函数 初始化互斥锁和记数
sp_counted_base(): use_count_( 1 ), weak_count_( 1 )
{
#if defined(__hpux) && defined(_DECTHREADS_)
pthread_mutex_init( &m_, pthread_mutexattr_default );
#else
pthread_mutex_init( &m_, 0 );
#endif
}

析构函数 释放互斥锁
virtual ~sp_counted_base() // nothrow
{
pthread_mutex_destroy( &m_ );
}


同步增加记数值，即根据原有的复制构造出或通过赋值产生新的代理时记数加1 
void add_ref_copy()
{
pthread_mutex_lock( &m_ );
++use_count_;
pthread_mutex_unlock( &m_ );
}

释放函数，在代理超界被析构时使用。 它首先减少引用记数， 
然后查看记数值，如果为0， 则调用dispose释放资源。并销毁掉本身
void release() // nothrow
{
pthread_mutex_lock( &m_ );
long new_use_count = --use_count_;
pthread_mutex_unlock( &m_ );

if( new_use_count == 0 )
{
dispose();
weak_release();
}
}

释放托管资源的函数。 为纯虚函数， 要求在子类中实现。 
只所以不同这个类中实现，是由于要托管的类型是未知的，如果要实现则要记录这个资源，则此类不得不模板化。 
将此功能分离到子类中的好处就非常明显。子类可以直接利用父类的功能，只要模板化一下，实现一个函数就行。 
这样会大大加快编译速度。

virtual void dispose() = 0; // nothrow

销毁函数。 在shared_count中的pi即记数器是New出来的。 
所以在适当的时候要销毁掉。 而这个时机就是资源被释放的时候。 
即记数器完成了对资源的管理， 同时完成了对自身的管理。

// destroy() is called when weak_count_ drops to zero.
virtual void destroy() // nothrow
{
delete this;
}


sp_counted_base_impl 类模板。 
一个属性

px : T* 记录各种类型的资源。

实现了父类的dispose函数。 实现对资源的释放。
virtual void dispose() // nothrow
{
#if defined(BOOST_SP_ENABLE_DEBUG_HOOKS)
boost::sp_scalar_destructor_hook( px_, sizeof(X), this );
#endif
boost::checked_delete( px_ );
}

3.2.4 工作流程

1 用户申请一个资源p
p = new Something();

2 用户将资源p托管给shared_ptr; 
shared_ptr(p);

2.1 shared_ptr 构造函数调用，构造出记数对象shared_count
shared_ptr() : px(p), pn(p)

2.1.1 shared_count 构造函数调用，构造出户数器对象
pi = new sp_counted_base_impl(p); 

3 用户使用shared_ptr对象sp, 就象直接使用资源一样
*sp;
sp->func();
.. 

4 如果用户要传递sp
shared_ptr spt = sp;

4.1 调用shared_ptr.operator=
4.1.1 调用shared_count.operator=
4.1.1.1 调用sp_counted_base复制构造
4.1.2 调用sp_counted_base.add_ref_copy， 增加引用记数

5 如果sp超出了它本身的作用域， 则调用析构函数
5.1 调用shared_count.~shared_count 析构记数
5.1.1 调用sp_counted_base.release, 减少引用记数
如果引用记数已经减少到0，则
调用sp_counted_base_impl.dispose, 销毁资源。
调用sp_counted_base.destroy, 销毁自身。

4 实践

上面是对boost::shared_ptr的分析。 整个过程就是对smart 
pointer这种观点的思考过程。 基本上是想到什么记录什么。 光说不练不行， 
根据对boost::shared_ptr的分析， 本人仿作了一个shared_ptr, 
可以看成是对boost::shared_ptr的一个简略版。 有没有用先不说， 反正都是写程序。

全部原代码见附件shared_ptr.tar.gz

5 参考
[1] boost www.boost.org
[2] shared_ptr性能分析 
http://blog.csdn.net/ralph623/archive/2005/08/18/458414.aspx
[3] smart pointer in boost 
http://www.ddj.com/dept/cpp/184401507?pgno=1
[4] the new C++: smart pointer  http://www.ddj.com/dept/cpp/184403837
[5] C++中的智能指针 
http://www.stlchina.org/twiki/bin/view.pl/Main/BoostProgrammSmartPoint