三言两语Sigslot

三言两语Sigslot

Sigslot 是一个小巧，却十分易用的开源C++信号插槽库。如果不想使用boost的signals库，Sigslot也不失为一个不错的选择，作者是Sarah Thompson,你可以通过[email protected]与他取得联系,相关文档在 http://sigslot.sourceforge.net/

 

  关于Sigslot的使用方法本文不再赘述，它的简单易用就已无需要太多的说明。在此对其代码结构进行一下大体的分析总结。

首先看下代码注释中 Quick documentation的简单描述：

 

【SIGSLOT_PURE_ISO】:

   强制设定其为ISO C++编译器，并关闭所有的操作系统提供的线程安全的支持。

【SIGSLOT_USE_POSIX_THREADS】:

   当使用gcc以外的编译器，而编译器支持Posix线程时，强制使用Posix线程支持。

   (gcc时该项是默认开启的，如果需要可以使用SIG_PURE_ISO关闭该项）

【SIGSLOT_DEFAULT_MT_POLICY】:

   当启用多线程支持时，默认项为全局多线程(multi_threaded_global)。否则默认项为单线程

   (single_threaded)。如果想更改默认，你需要自己定义该项。在纯ISO模式中，single_threaded以外的

   内容都会触发编译错误。

 

 关于操作系统的说明：

   Win32:

     Win32系统中，必须定义WIN32宏。大多数主流的编译器会默认定义该宏，但是你当你的编译环境并不是很

     标准的时候，必须有你自己定义。以便于Win32线程支持部分被编译并自动启动。

 

    Unix/Linux/BSD,etc:

     如果你正在使用gcc，则默认Posix线程是可用的，所以会自动使用Posix线程部分代码。使用   

     SIGLOT_PURE_ISO可以关闭这个默认项（在Windows中）。如果你gcc以外的编译器，但是仍然想使用    Posix线程部分的代码，
     你必须#define SIGSLOT_USE_POSIX_THREADS

    ISO C++:

      如果处于不支持多线程的操作系中，或者定义了SIGSLOT_PURE_ISO宏时，所有多线程支持就被关闭，连
      同可能在会纯ISO C++环境中会引发任何编译器警告的代码也不会被使用。我会在你提出疑问前，直接告诉
      你gcc -ansi  -pedantic选项不会成功编译，但是gcc -ansi没有问题。Pedantic选项似乎会引发大量的
      奇怪错误。如果你想研究这个问题，请联系作者。

 

 关于线程模型：

    single_threaded:
      由于signal/slot的使用方式，程序设定为了单线程模型（例如所有的信号对象和槽对象都是有一个单线程
      创建和销毁的）没有定义相关保证对象销毁一致性的行为（例如：会得到对已销毁对象使用的错误或者触发内存异常）

  

    multi_threaded_global:

      程序设定多线程模型。使用信号和插槽的对象能够被任一线程安全的创建和销毁，甚至发生在信号和插槽的
      连接已经建立的情况中。multi_threaded_global模型，依靠唯一的全局的互斥体实现线程安全（实际上
      windows中是使用临界区因为性能更好）。该模型使用少量的系统资源，但是导致更多产生资源竞争的机
      会，或许，因此产生更多的设备上下文切换是无法避免的。

  

   multi_threaded_local:

      该模型的机制本质上跟multi_threaded_global是没有太大区别的，除了各个信号和对象都各自继承自
      has_slots，他们都具备各自的互斥体/临界区部分。实际上， 这意味着互斥体冲突的状况（因此产生的设备
     上下文 切换）只会在最必要的时候才会发生 。无论如何在某些操作系统中，创建大量的互斥体会减慢整个操
     作系统的运行速度，所以使用该模型最好谨而为之。

     #if defined(SIGSLOT_PURE_ISO) || (!defined(WIN32) && !defined(__GNUG__) && !defined(SIGSLOT_USE_POSIX_THREADS))
#    define _SIGSLOT_SINGLE_THREADED         //单线程模型
#elif defined(WIN32)
#    define _SIGSLOT_HAS_WIN32_THREADS    //WIN32多线程模型
#    include <windows.h>
#elif defined(__GNUG__) || defined(SIGSLOT_USE_POSIX_THREADS)
#    define _SIGSLOT_HAS_POSIX_THREADS    //POSIX多线程模型
#    include <pthread.h>
#else
#    define _SIGSLOT_SINGLE_THREADED        //单线程模型
#endif

#ifndef SIGSLOT_DEFAULT_MT_POLICY          //默认多线程模型策略
#    ifdef _SIGSLOT_SINGLE_THREADED          //如果强制指定为单线程模型则默认策略为单线程
#        define SIGSLOT_DEFAULT_MT_POLICY single_threaded       
#    else
#        define SIGSLOT_DEFAULT_MT_POLICY multi_threaded_local //否则默认策略为local多线程模型
#    endif
#endif

对于 单线程模型single_threaded，lock(),unlock()保留为空函数。
多线程模型中 针对_SIGSLOT_HAS_WIN32_THREADS和_SIGSLOT_HAS_POSIX_THREAD 开关，对应了Win32和Posix两个系统平台，因为不同平台使用不同的线程同步对象，所以分别实现两类平台下的两种 multi_threaded_global、multi_threaded_local版本。在Posix中使用了 pthread_mutex_t作为线程同步对象，Win32中使用 CRITICAL_SECTION作为线程同步对象。

我们可以看到在所有的模板类中都有一个mt_policy模板参数，有意思的是
template<class mt_policy = SIGSLOT_DEFAULT_MT_POLICY>这并不是多此一举，若将mt_policy直接替换为SIGSLOT_DEFAULT_MT_POLICY，不仅代码变得凌乱丑陋，代码而且维护性也会大大降低。

锁对象：
lock_block模板类，最终根据实例化的模板类使用相应的线程模型和同步对象，只需要将该类实例化到需要的位置即实现了线程同步功能，这是比较规范并简单有效的方法。

    template<class mt_policy>
class lock_block
{
    public:
    mt_policy *m_mutex;

    lock_block(mt_policy *mtx) : m_mutex(mtx)
    {
        m_mutex->lock();
    }
    ~lock_block()
    {
        m_mutex->unlock();
    }
}; 

 

mt_policy被指定为SIGSLOT_DEFAULT_MT_POLICY宏，同时也作为一个强制指定为单线程模型的开关。

连接对象 _connection0 ... _connection8：

_connection0<dest_type,mt_policy>...
_connection8<dest_type,arg1_type...arg8_type,mt_policy>
是接口:
_connection_base0<mt_policy> ...
_connection_base8<arg1_type,...arg8_type,mt_policy>的实现类，其中：

clone():
使用默认拷贝构造函数返回一个新的_connection_baseN对象指针。

duplicate(sigslot::has_slots<mt_policy> *pnewdest):
返回一个新的目标对象为pnewdest的_connection_baseN对象指针。

emit(arg0_type a0..argN_type aN):
触发_connection_baseN中目标对象中指定的函数指针。

getdest(void)const:
返回目标对象指针。

插槽has_slots<mt_policy>：

类has_slots<mt_policy>为所有具备插槽对象的基类，也就是说，任何想接收信号，并将信号连接到处理函数（插槽）的对象都必须继承自has_slots类。

     private:
    typedef typename std::set<_signal_base<mt_policy> *> sender_set;
    typedef typename sender_set::const_iterator const_iterator;
    sender_set m_senders;

senders 为 _signal_base<mt_policy> 接口指针容器，用于维护一系列signal0..signal8实例。

signal_disconnect和 signal_connect成员函数用于管理_signal_base<mt_policy>指针列表 m_senders的插入与删除（最终由信号对象signalN的

connect(desttyp *pclass,void(desttype::*pmemfun)() 函数直接使用。）。实际上即使对信号与插槽的维护。


信号对象 Signal0 ... Signal8 ：

以带一个参数的信号对象为例： signal1<arg1_type,mt_policy>的 emit(arg1_type a1) 与 重载运算符 operator ()(arg1_type a1)功能是一致的。都是遍历父类成员 m_connected_slots中的_connection_base1<arg1_type, mt_policy>指针元素，逐一的调用_connection_base1中的 emit(a1)函数最终使目标函数被调用。

函数 connect（）生成模板参数的目标对象和目标函数指针，并将该新连接加入到已连接的列表 m_connected_slots中。最后使用has_slots的signal_connect函数，将signal1信号对象加入到has_slots的 m_senders列表中。代码如下：

      template<class desttype>
void connect(desttype* pclass, void (desttype::*pmemfun)(arg1_type))
{
    lock_block<mt_policy> lock(this);
     _connection1<desttype, arg1_type, mt_policy>* conn =
    new _connection1<desttype, arg1_type, mt_policy>(pclass, pmemfun);
    m_connected_slots.push_back(conn);
    pclass->signal_connect(this);
}