Libevent源码分析-----多线程、锁、条件变量(二)

Debug锁操作：      

         Libevent还支持对锁操作的一些检测，进而捕抓一些典型的锁错误。Libevent检查：

• 解锁自己(线程)没有持有的锁
• 在未解锁前，自己(线程)再次锁定一个非递归锁。

        Libevent通过一些变量记录锁的使用情况，当检查到这些锁的错误使用时，就调用abort，退出运行。

开启调试功能：

        用户只需在调用evthread_use_pthreads或者evthread_use_windows_threads之后，调用evthread_enable_lock_debuging()函数即可开启调试锁的功能。该函数有一个拼写错误。在2.1.2-alpha版本中会改正为evthread_enable_lock_debugging，为了后向兼容，两者都会支持的。

        现在看一下Libevent是锁调试功能。

 //evthread.c文件
 void
 evthread_enable_lock_debuging(void)
 {
     struct evthread_lock_callbacks cbs = {
         EVTHREAD_LOCK_API_VERSION,
         EVTHREAD_LOCKTYPE_RECURSIVE,
         debug_lock_alloc,
         debug_lock_free,
         debug_lock_lock,
         debug_lock_unlock
     };
     if (_evthread_lock_debugging_enabled)
         return;

     //把当前用户定制的锁操作复制到_original_lock_fns结构体变量中。
     memcpy(&_original_lock_fns, &_evthread_lock_fns,
         sizeof(struct evthread_lock_callbacks));

     //将当前的锁操作设置成调试锁操作。但调试锁操作函数内部
     //还是使用_original_lock_fns的锁操作函数
     memcpy(&_evthread_lock_fns, &cbs,
         sizeof(struct evthread_lock_callbacks));

     memcpy(&_original_cond_fns, &_evthread_cond_fns,
         sizeof(struct evthread_condition_callbacks));
     _evthread_cond_fns.wait_condition = debug_cond_wait;
     _evthread_lock_debugging_enabled = 1;

     /* XXX return value should get checked. */
     event_global_setup_locks_(0);
 }

        在上面代码的注释可以知道，虽然evthread_lock_fns的值被更新为debug_lock_alloc、debug_lock_lock和debug_lock_unlock。但实际上，使用的还是之前用户定制的线程锁操作函数，只是加多了一层抽象而已。如果看不懂这段话，可以看下面的代码，看完已经就会懂的了。

 //evthread.c文件
 static void *
 debug_lock_alloc(unsigned locktype)
 {
     struct debug_lock *result = mm_malloc(sizeof(struct debug_lock));
     if (!result)
         return NULL;

     //用户设置过自己的线程锁函数
     if (_original_lock_fns.alloc) {
         //用用户定制的线程锁函数分配一个线程锁
         if (!(result->lock = _original_lock_fns.alloc(
                 locktype|EVTHREAD_LOCKTYPE_RECURSIVE))) {
             mm_free(result);
             return NULL;
         }
     } else {
         result->lock = NULL;
     }
     result->locktype = locktype;
     result->count = 0;
     result->held_by = 0;
     return result;
 }

        现在看看Libevent是怎么调试（更准确来说，应该是检测）锁的。锁的检测，需要用到debug_lock 结构体，它对锁的一些使用状态进行了记录。

debug递归锁：

 //evthread.c文件
 struct debug_lock {
     unsigned locktype; //锁的类型
     unsigned long held_by; //这个锁是被哪个线程所拥有
     /* XXXX if we ever use read-write locks, we will need a separate
      * lock to protect count. */
     int count; //这个锁的加锁次数
     void *lock; //锁类型，在pthreads下为pthread_mutex_t*类型
 };

 static int
 debug_lock_lock(unsigned mode, void *lock_)
 {
     struct debug_lock *lock = lock_;
     int res = 0;
     if (lock->locktype & EVTHREAD_LOCKTYPE_READWRITE)
         EVUTIL_ASSERT(mode & (EVTHREAD_READ|EVTHREAD_WRITE));
     else
         EVUTIL_ASSERT((mode & (EVTHREAD_READ|EVTHREAD_WRITE)) == 0);
     if (_original_lock_fns.lock)
         res = _original_lock_fns.lock(mode, lock->lock);
     //lock 成功返回0，失败返回非0
     if (!res) {
         //记录这个锁的使用情况。
         evthread_debug_lock_mark_locked(mode, lock);
     }
     return res;
 }

 static void
 evthread_debug_lock_mark_locked(unsigned mode, struct debug_lock *lock)
 {
     ++lock->count; //增加锁的加锁次数.解锁时会减一
     if (!(lock->locktype & EVTHREAD_LOCKTYPE_RECURSIVE))
         EVUTIL_ASSERT(lock->count == 1);
     if (_evthread_id_fn) {
         unsigned long me;
         me = _evthread_id_fn(); //获取线程ID
         if (lock->count > 1)
             EVUTIL_ASSERT(lock->held_by == me);
         lock->held_by = me; //记录这个锁是被哪个线程所拥有
     }
 }

        这里主要是测试一个锁类型(如pthread_mutex_t)同时被加锁的次数。如果是一个非递归锁，那么将不允许多次锁定。对于锁的实现没有bug的话，如果是非递归锁，那么会在第二次锁住同一个锁时，卡死在debug_lock_lock 函数的original_lock_fns.lock上(即发生了死锁)。此时evthread_debug_lock_mark_locked是不会被调用的。但是，对于一个有bug的锁实现，那么就有可能发生这种情况。即对于非递归锁，其还是可以多次锁住同一个锁，并且不会发生死锁。此时，evthread_debug_lock_mark_locked函数将会被执行，在这个函数内部将会检测这种情况。Libevent的锁调试(检测)就是调试(检测)这种有bug的锁实现。

debug解锁：

        现在看一下解锁时的检测。这主要是检测解锁一个自己没有锁定的锁，比如锁是由线程A锁定的，但线程B却去解锁。

 //evthread.c文件。
 static int
 debug_lock_unlock(unsigned mode, void *lock_)
 {
     struct debug_lock *lock = lock_;
     int res = 0;
     //先检测
     evthread_debug_lock_mark_unlocked(mode, lock);
     if (_original_lock_fns.unlock)
         res = _original_lock_fns.unlock(mode, lock->lock);
     return res;
 }

 static void
 evthread_debug_lock_mark_unlocked(unsigned mode, struct debug_lock *lock)
 {
     if (lock->locktype & EVTHREAD_LOCKTYPE_READWRITE)
         EVUTIL_ASSERT(mode & (EVTHREAD_READ|EVTHREAD_WRITE));
     else
         EVUTIL_ASSERT((mode & (EVTHREAD_READ|EVTHREAD_WRITE)) == 0);
     if (_evthread_id_fn) {
         //检测锁的拥有者是否为要解锁的线程
         EVUTIL_ASSERT(lock->held_by == _evthread_id_fn());
         if (lock->count == 1)
             lock->held_by = 0;
     }
     --lock->count;//减少被加锁次数
     EVUTIL_ASSERT(lock->count >= 0);
 }

        从代码中可以看到，这里主要是检测解锁的线程是否为锁的实际拥有者。即检测是否解锁一个自己不拥有的锁。这里不是为了检测锁的实现是否有bug，而是检测锁在使用的时候是否有bug。

        当然Libevent提供的检测能力还是很有限的。特别是对于前一个检测，如果是使用Windows线程锁或者pthreads线程锁，这个检测并没有什么用。毕竟这些锁的实现已经经过了千锤百炼。

定制线程锁、条件变量：

        现在来看一下线程锁定制函数evthread_set_lock_callbacks。本来这个定制应该放在前一篇博客讲的。但由于其实现用到了调试锁的一些内容，所以就放到这里讲。

 //evthread.h文件
 int
 evthread_set_lock_callbacks(const struct evthread_lock_callbacks *cbs)
 {
     struct evthread_lock_callbacks *target =
         _evthread_lock_debugging_enabled //默认为0
         ? &_original_lock_fns : &_evthread_lock_fns;

     if (!cbs) {//参数为NULL，取消线程锁功能
         if (target->alloc)
             event_warnx("Trying to disable lock functions after "
                 "they have been set up will probaby not work.");
         memset(target, 0, sizeof(_evthread_lock_fns));
         return 0;
     }

     //一旦设置就不能修改
     if (target->alloc) {
         /* Uh oh; we already had locking callbacks set up.*/
         if (target->lock_api_version == cbs->lock_api_version &&
             target->supported_locktypes == cbs->supported_locktypes &&
             target->alloc == cbs->alloc &&
             target->free == cbs->free &&
             target->lock == cbs->lock &&
             target->unlock == cbs->unlock) {
             /* no change -- allow this. */
             return 0;
         }
         event_warnx("Can't change lock callbacks once they have been "
             "initialized.");
         return -1;
     }

     //这个四个函数指针都不为NULL时才能成功定制。因为这四个函数是配套使用的
     if (cbs->alloc && cbs->free && cbs->lock && cbs->unlock) {
         memcpy(target, cbs, sizeof(_evthread_lock_fns));
         return event_global_setup_locks_(1);
     } else {
         return -1;
     }
 }

        全局变量_evthread_lock_debugging_enabled的初始化值为0，当调用evthread_enable_lock_debuging函数后其值为1。于是，无论是在调试锁还是非调试的情况下，target变量都能够修改实际使用的evthread_lock_callbacks结构体（线程锁操作函数指针结构体）。前面已经说到了，在非调试情况下，实际使用的是_evthread_lock_fns变量的线程锁函数指针成员。在调试情况下实际使用的是_original_lock_fns变量的。

        从上面的代码中也可以看到：当参数为NULL时，就等于取消了线程锁功能。此后，Libevent的代码将运行在没有线程锁的无线程安全状态下。

        上面的第二个if语句则说明，在已经定制了线程锁之后，是无法再次定制的。我觉得这主要是怕：这个修改线程锁的动作刚好发生在另外一个线程获取获取锁的之后，即调用lock函数之后。并且是在另外的线程释放锁之前，即调用unlock函数之前。如果允许修改锁定制的线程锁，那么将可能发生，加锁和解锁操作是完全不同的两套线程锁。

        前面说到参数cbs可以为NULL，其实这就给了我们一个修改定制线程锁的方法。我们可以先用NULL作为参数调用一次evthread_set_lock_callbacks函数，然后用真正的线程锁方案作为参数，再次调用evthread_set_lock_callbacks函数。当然这相当容易发生bug。后面也会给出一个例子。

锁的使用：

加锁和解锁：

        Libevent中，一些函数支持多线程。一般都是使用锁进行线程同步。在Libevent的代码中，一般是使用EVTHREAD_ALLOC_LOCK宏获取一个锁变量，EVBASE_ACQUIRE_LOCK宏进行加锁，EVBASE_RELEASE_LOCK宏进行解锁。在阅读Libevent源代码中，一般都只会看到EVBASE_ACQUIRE_LOCK和EVBASE_RELEASE_LOCK。锁的内部实现是看不见的。

        现在对EVBASE_ACQUIRE_LOCK进行深究，看其是怎么一层层地封装的。先看event_add函数的实现：

 //event.c文件
 int
 event_add(struct event *ev, const struct timeval *tv)
 {
     int res;

     if (EVUTIL_FAILURE_CHECK(!ev->ev_base)) {
         event_warnx("%s: event has no event_base set.", __func__);
         return -1;
     }
     //加锁
     EVBASE_ACQUIRE_LOCK(ev->ev_base, th_base_lock);

     res = event_add_internal(ev, tv, 0);
     //解锁
     EVBASE_RELEASE_LOCK(ev->ev_base, th_base_lock);

     return (res);
 }

        其中，EVBASE_ACQUIRE_LOCK是一个条件宏。

 //evthread-internal.h文件
 #ifndef WIN32
 #define EVTHREAD_EXPOSE_STRUCTS
 #endif


 #if ! defined(_EVENT_DISABLE_THREAD_SUPPORT) && defined(EVTHREAD_EXPOSE_STRUCTS)

 #define EVLOCK_LOCK(lockvar,mode)                   \
     do {                                \
         if (lockvar)                        \
             _evthread_lock_fns.lock(mode, lockvar);     \
     } while (0)

 #define EVBASE_ACQUIRE_LOCK(base, lockvar) do {             \
         EVLOCK_LOCK((base)->lockvar, 0);         \
     } while (0)


 #elif ! defined(_EVENT_DISABLE_THREAD_SUPPORT)

 int _evthreadimpl_lock_lock(unsigned mode, void *lock);


 #define EVLOCK_LOCK(lockvar,mode)                   \
     do {                                \
         if (lockvar)                        \
             _evthreadimpl_lock_lock(mode, lockvar);     \
     } while (0)

 #define EVBASE_ACQUIRE_LOCK(base, lockvar) do {             \
         EVLOCK_LOCK((base)->lockvar, 0);         \
     } while (0)


 #else //不支持多线程
 #define EVBASE_ACQUIRE_LOCK(base, lock)  ((void)0)

 #endif


 //evthread.c文件
 int
 _evthreadimpl_lock_lock(unsigned mode, void *lock)
 {
     if (_evthread_lock_fns.lock)
         return _evthread_lock_fns.lock(mode, lock);
     else
         return 0;
 }

        虽然是条件宏，但最终都是调用了_evthread_lock_fns结构体中的lock指针指向的函数，即调用了定制锁的锁函数，进行了锁定。但不同的是，在第一种宏中，并没有对_evthread_lock_fns.lock这个指针作是否为NULL判断，而第二种宏，会在_evthreadimpl_lock_lock对这个指针进行判断，当这个指针不为NULL时才进行函数调用。

        在非Windows系统上会把EVBASE_ACQUIRE_LOCK宏定义成第一种情况。但在Linux上调用event_add时，即使_evthread_lock_fns.lock为NULL也没有出现段错误。

        实际上，虽然第一种情况没有对_evthread_lock_fns.lock进行判断，但它对lockvar进行了判断。但Lockvar为何物？顺藤摸瓜，lockvar为event_base结构体中的th_base_lock成员，类型为viod*。实际上，lockvar就是申请得到的锁变量。下面代码将看到如何申请。如果th_base_lock为NULL，那么就不会对_evthread_lock_fns.lock这个函数指针进行函数调用了。

        在event_base_new_with_config函数可以看到th_base_lock成员的赋值情况。

 struct event_base *
 event_base_new_with_config(const struct event_config *cfg)
 {
     struct event_base *base;

     //之所以不用mm_malloc是因为mm_malloc并不会清零该内存区域。
     //而这个函数是会清零申请到的内存区域。这相当于给base初始化
     if ((base = mm_calloc(1, sizeof(struct event_base))) == NULL) {
         event_warn("%s: calloc", __func__);
         return NULL;
     }

         …….//其他成员的初始化

 #ifndef _EVENT_DISABLE_THREAD_SUPPORT

     //对于th_base_lock变量，目前的值为NULL.
    //EVTHREAD_LOCKING_ENABLED宏是测试_evthread_lock_fns.lock
    //是否不为NULL
     if (EVTHREAD_LOCKING_ENABLED() &&
         (!cfg || !(cfg->flags & EVENT_BASE_FLAG_NOLOCK))) {
         int r;
         EVTHREAD_ALLOC_LOCK(base->th_base_lock, //申请锁变量
             EVTHREAD_LOCKTYPE_RECURSIVE);
     }
 #endif

     …..
     return (base);
 }

        从这里可以看到，如果_evthread_lock_fns.lock为NULL，那么th_base_lock成员肯定为NULL，那么后面就不会调用_evthread_lock_fns.lock()函数。从而避过段错误。

        会不会th_base_lock不为NULL，而_evthread_lock_fns.lock为NULL呢？

        th_base_lock是由要_evthread_lock_fns.lock非NULL，才会被赋值为非NULL。如果_evthread_lock_fns.lock为NULL，那么th_base_lock就肯定为NULL了。此外，结构体event_base是定义是event_internal.h文件的。所以，正常情况下，该结构体的成员是不可见的。所以你是无法直接访问并修改其成员。

        其实，有一种可能达到目标。就是先把_evthread_lock_fns.lock赋值成非NULL，然后用来把th_base_lock赋值成非NULL，之后把_evthread_lock_fns.lock修改为NULL。下面是Libevent提供的定制线程锁的函数evthread_set_lock_callbacks。

 int
 evthread_set_lock_callbacks(const struct evthread_lock_callbacks *cbs)
 {
     …..
     if (!cbs) {//参数为NULL，取消线程锁功能
         if (target->alloc)
             event_warnx("Trying to disable lock functions after "
                 "they have been set up will probaby not work.");
         memset(target, 0, sizeof(_evthread_lock_fns));
         return 0;
     }
     …..
 }

        从代码中可以看到，当参数cbs为NULL时，是可以取消线程锁功能的。可以尝试编译运行下面的代码。代码一运行就可以看到段错误了。

 #include  <event.h>
 #include  <thread.h>
 #include  <unistd.h>

 void cmd_cb(int fd, short event, void *arg)
 {

 }

 int main()
 {
     evthread_use_pthreads();

     event_base *base = event_base_new();

     evthread_set_lock_callbacks(NULL);

     event *cmd_event = event_new(base, STDIN_FILENO, EV_READ | EV_PERSIST,
                                  cmd_cb, base);
     event_add(cmd_event, NULL);

     event_base_dispatch(base);

     return 0;
 }

         从这里可以看到，一旦设置了线程、锁函数，那么就不应该对其进行修改。

        值得注意的是，在Libevent中，像EVBASE_ACQUIRE_LOCK这个宏是专门给event_base用的。

断言已加锁：

        在Libevent中，很多线程安全的函数都会调用一个已加锁断言。确保在进入这函数的时候，已经获得了一个锁。一般是调用EVENT_BASE_ASSERT_LOCKED(base);完成这个断言。要注意的是：这个已锁断言要在开启了调试锁的前提下，才能使用的。

        下面代码可以看到断言锁是怎么实现的：

 EVENT_BASE_ASSERT_LOCKED(base);

 #define EVENT_BASE_ASSERT_LOCKED(base)      \
     EVLOCK_ASSERT_LOCKED((base)->th_base_lock)


 #define EVLOCK_ASSERT_LOCKED(lock)                  \
     do {                                \
         if ((lock) && _evthread_lock_debugging_enabled) {   \
             EVUTIL_ASSERT(_evthread_is_debug_lock_held(lock)); \
         }                           \
     } while (0)


 int
 _evthread_is_debug_lock_held(void *lock_)
 {
     struct debug_lock *lock = lock_;
     if (! lock->count)
         return 0;
     if (_evthread_id_fn) {
         unsigned long me = _evthread_id_fn();
         if (lock->held_by != me)
             return 0;
     }
     return 1;
 }

        从EVLOCK_ASSERT_LOCKED宏的判断可以知道，_evthread_lock_debugging_enabled要不为0。而它的赋值是由evthread_enable_lock_debuging()完成的，这个函数的作用就是开启锁调试功能。

        前面在讲调试锁的时候，有说到evthread_debug_lock_mark_locked函数，这个函数在加锁的时候会被调用。该函数会记录锁是由哪个线程加的，具体实现是通过记录线程ID。面的_evthread_is_debug_lock_held函数的功能就是测试本线程ID是否等于之前加锁的线程ID。这样就完成了已加锁断言。

参考：

        http://www.wangafu.net/~nickm/libevent-book/Ref1_libsetup.html