几种线程安全的 加锁方式

对容器的包装加锁

 

#ifndef THREADSAFEOBJECT_H_HEADER_GUARD_
#define THREADSAFEOBJECT_H_HEADER_GUARD_

template<class T>
class ThreadSafeObject
{
public:
     ThreadSafeObject(T* type):m_type(type)
     {
      InitializeCriticalSection(&m_cs);
     }
    
     ~ThreadSafeObject()
     {
          EnterCriticalSection (&m_cs);
          delete m_type;m_type=NULL;
          LeaveCriticalSection(&m_cs);
          DeleteCriticalSection(&m_cs);
     }
    
     // 引用锁
     class RefLock
     {
     public:
          RefLock(T* type, CRITICAL_SECTION &cs):m_type(type), m_cs(cs)
          {
           EnterCriticalSection (&m_cs);
          }
         
          RefLock(const RefLock& Src):m_type(Src.m_type), m_cs(Src.m_cs){ EnterCriticalSection (&m_cs);}
          ~RefLock(){LeaveCriticalSection(&m_cs);}
          inline T* operator->() const{return m_type;}
          inline T& operator*() const{return m_type;}
          T* m_type;
     private:
          CRITICAL_SECTION &m_cs;
     };
     RefLock GetLockedObject()
     {
          return RefLock(m_type, m_cs);
     }
    
private:
     T* m_type;
     CRITICAL_SECTION m_cs;
     ThreadSafeObject(const ThreadSafeObject&);
     ThreadSafeObject& operator=(const ThreadSafeObject&);
};

#endif //!THREADSAFEOBJECT_H_HEADER_GUARD_

 

DXUT 的加锁方法 非常值得借鉴

//--------------------------------------------------------------------------------------
// Thread safety
//--------------------------------------------------------------------------------------
CRITICAL_SECTION g_cs; 
bool g_bThreadSafe = true;

//--------------------------------------------------------------------------------------
// Automatically enters & leaves the CS upon object creation/deletion
//--------------------------------------------------------------------------------------
class DXUTLock
{
public:
    inline DXUTLock()  { if( g_bThreadSafe ) EnterCriticalSection( &g_cs ); }
    inline ~DXUTLock() { if( g_bThreadSafe ) LeaveCriticalSection( &g_cs ); }
};

 

 

让stl容器成为线程安全的一个办法

作者    wingfiring (非典型秃子)
来源    http://community.csdn.net/Expert/topic/5428/5428646.xml?temp=2.718753E-02

正文:


自我感觉很有趣的技术，共享^_^
http://blog.csdn.net/wingfiring/archive/2007/03/28/1543811.aspx

如果你有编写多线程程序的经历，遇到过需要共享对象的情况吗？比如，你想在两个线程中操作同一个容器，你会怎么做呢？是在每个地方都小心翼翼地加锁，还是封装一个来用？两种方法我都用过，但我比较青睐封装一个的办法，例如，封装一个带锁的队列，用于线程间的通信．
　　让我们先看看直接操作锁和对象的代码：
//declare:
std::Container cont;
LockType contLock;
...
//using:
contLock.lock();
cont.XXX();
contLock.unlock();
　　嗯，using下面的加锁和解锁的方法太老土，而且最关键的，还不安全，让我们稍加改善：
ScopedLock guard(contLock);  //在ScopedLock的构造函数中lock，在析构函数中unlock
cont.XXX();
    看上去稍好了一点，然而有两个小的缺点。前面提到共享对象，第一个缺点就是我们需要共享两个对象，容器和锁，这使得管理和传递共享对象都变得麻烦起来。另一个缺点是，加锁的动作需要小心谨慎，千万别忘了。可惜，即使忘了，我们也不会从编译器这里得到任何帮助。这两个不便，都会促使我们考虑是不是把对象和锁封装起来更好？很多时候，我们确实是这么做的，看一个deque的例子（省略std）.
template<typename T, typename Alloc= allocator<T> >
class shared_deque{
    dequeT, Alloc> m_cont;
    LockType   m_lock;
    ...
    void push_back(const_reference val){
       ScopedLock guard(m_lock);
       m_cont.push_back(val);
    }
    ....
};
    呼，终于好了，我们现在有了一个好用的shared_queue了。只是，类似那个push_back的东西，重复了几十遍，很无聊的，还有必要对 list也来一遍吗？算了吧！万幸，没有用basic_string，那家伙可有１００多个成员函数。有没有办法简化一下工作呢？重复的东西总是应该交给计算机来做是不是？还好，C++正好能帮助我们实现这一目标，这个手法在MCD中被寥寥数语带过，就是那神奇的operator->()．
   让我们回顾一下operator->的用法：用于对象指针，提取对象成员，函数或对象．许多smart pointer地实现都重载了这个运算符，从而可以模拟指针的语法．一般的重载形式是这样的：
cv1 T* operator->() cv2
   这里返回的是T*类型，如果返回的不是指针类型呢？C++标准对此有特别规定，会继续调用返回值的operator->()方法，直到最终解析出一个指针类型．假定有下面的operator->展开过程：
object a-->b-->T pointer
(请注意一下a,b,T对象的生命期，确定我们是安全地在使用这些对象．)a对象的operator->返回临时对象b,b对象的operator ->返回最终类型T*.那么，b对象必须在其T* operator->()调用之前创建好，而在T::XXX()方法调用之后被销毁，因为b是临时对象．嗯，好了，有点方向了：在b的构造函数中加锁，在析构中解锁，就可以在调用T::XXX()方法时自动实现加锁可解锁了．
　　拓展一下思维，我们必须局限于锁和容器吗？不必．这个手法的本质效果是什么？就是在调用一个方法之前，插入一些操作，调用之后再插入一些操作（稍显遗憾的是，我们无法知道被调用的到底是什么方法）．但是，这也够我们做许多事情了．实现如下：
#include
    template
    <
        typename Pointer,
        typename Monitor,
        typename ScopedType = typename Monitor::scope_type
    >
    class call_proxy
    {
    public:
        typedef call_proxy self_type;
        typedef Pointer pointer_type;
        typedef Monitor monitor_type;
        typedef ScopedType scoped_type;

        typedef typename boost::call_traits<pointer_type>::param_type param_type;      
        typedef monitor_type& monitor_reference;

    private:      
        struct proxy{
            proxy(self_type* host) : m_host(host), m_s(host->m_monitor){};
            pointer_type operator->(){
                return m_host->m_obj;
            }
        private:
            self_type* m_host;
            scoped_type m_s;
            proxy(const proxy&);
            proxy& operator=(const proxy&)
        };
        friend struct proxy;
    public:
        call_proxy(param_type p, monitor_reference m) : m_obj(p), m_monitor(m){ assert(p);}

        proxy operator->() {
            return this;
        }
    private:
        pointer_type m_obj;
        boost::reference_wrapper<monitor_type> m_monitor;
    };
///
// 其中第二个模板参数Monitor的类大致如下：
// class LockType{
//    void lock();//private!
//    void unlock();
//    //disable copy ctor & assignment
// public:
//    friend class scoped_lock;
//    class scoped_lock{
//         LockType& m_l;
//         //disable copy ctor & assignment
//    public:
//         explicit scoped_lock(LockType& l) : m_l(l){ m_l.lock();}
//         ~scoped_lock(){ m_l.unlock();}
//    };
// };
// 大致如此，更详细的实现可以参考boost.thread.mutex的实现。Loki.thread中也有类似实现,不过看上去不像上面这么直接。
/

为了可以和smart_pointer合作，call_proxy需要的第一个模版参数是被代理对象的指针类型，而不是自己产生指针类型，这就允许是一个 smart_pointer的类型．monitor类型本质上需要开始和结束两个方法，把它封装进ScopedType,依靠ScopedType的构造和析构来完成．这样做的目的是避免对限制monitor的方法名称，可以看作是traits手法的简化版本．你可以自定义合适的ScopedType类型．嵌套类proxy的构造函数的隐式转换是必要的，它可以消除额外的copy ctor的需求．
　　上述的实现代码已经没什么神奇之处可言了．使用方法如下：
    typedef vector<int> MyVector;
    MyVector cont;
    LockType lock;
    typedef call_proxy<MyVector*, LockType, LockType::scoped_lock> proxy_type;
    proxy_type cont_proxy(&cont, lock);
    至此，cont_proxy可以作为一个封装好的对象使用了．嗯，当然，cont_proxy的生命周期应该比cont来得短，这个问题就让程序员去保证吧．
剩下的问题：
　　call_proxy还有一些问题需要解决．我们在调用某些成员方法的时候，未必都要加锁．如果对象和锁是分离的，那么自然很容易处理．如果是手工封装，虽然工程浩大，但是也可以在适当的地方加以特别处理．特别的，对于分离的对象和锁，我们还可以使用大粒度的锁定过程，从而改善某些性能．而这里的 call_proxy则没有这种灵活性，当然手工封装的类也无此灵活性．然而，我们还是可以改善call_proxy，从而在一定程度上获得这种灵活性的好处，为call_proxy增加两个友元方法：
    friend pointer_type getImp(const self_type& cp){ return cp.m_obj;}
    friend monitor_reference getMonitor(const self_type& cp){ return cp.m_monitor;}
当我们需要大粒度的机制时可以这样：
{
    proxy_type::scoped_type guard(getMonitor(cont_proxy));
    getImp(cont_proxy)->XXX1();
    getImp(cont_proxy)->XXX2();
    ...
}
对于新手，可能会奇怪getImp的用途，或者忘记调用，这不够优雅．但是这样的解决方案已经比较简单了，它简化了大部分的情况，而且留了一条优化的后路．