在资源管理器中小心copying行为
上节是对资源的管理说明。有时候我们不能依赖于shared_ptr或者auto_ptr,所以我们须要自己建立一个资源管理类来管理自己的资源。
比如建立一个类来管理Mutex锁。如今使用函数处理类型为Mutex的相互排斥器对象
class Lock{
public:
explicit Lock(Mutex* mu):mutexPtr(mu)
{
lock(mutexPtr);
}
~Lock()
{
unlock(mutexPtr);
}
private:
Mutex* mutexPtr;
};
void lock(Mutex* mu);//加锁
void unlock(Mutex* mu);//解锁
Mutex m;//定义相互排斥器
……
{
Lock(&m);
……
}
以上代码能够完毕对资源的释放,这里的释放对于mutex来说的真正意义就是解锁。而不是销毁。
然而。以上代码是有问题的,比方运行Lock m2(m1);这句话时。我们须要怎么面对?难道就是两个对象交互的操纵mutex?这样做绝对不行,我们不能确定什么时候m2和m1会被析构,一旦被析构就会导致mutex解锁,mutex一旦解锁就会被别的进程所调用,程序将出现巨大的混乱!
解决上述问题一般有下面几种方式:
1、禁止复制
很多情况下,复制RAII对象并不合理。比如Lock类,这时候便能够禁止复制。仅仅需将coping函数设为私有。条款6有讲述
2、对管理资源使用引用计数法。模仿shared_ptr
3、复制底部资源。这里要是深拷贝
4、转移底层资源的拥有权。
模仿auto_ptr.
作者举出另外一种方式的详细操作。例如以下:
class Lock:private Uncopyable{
public:
explicit Lock(Mutex* mu):mutexPtr(mu,unlock)//以某个Mutex初始化。unlock作为删除其
{
lock(mutexPtr);
}
private:
shared_prt<Mutex> mutexPtr;
};
假设上述Lock类使用引用计数器的话,仅仅需把mutexPrt变为类型从Mutex*变为shared就可以。但shared_ptr默认是当引用计数为0时,删除多指向对象,这不是我们想要的,我们想要的是调用unlock函数。幸运的是在shared_ptr中同意指定“删除器”。即引用计数为0时调用的函数。
时间: 2024-10-14 13:27:50