Libevent还支持对锁操作的一些检测，进而捕抓一些典型的锁错误。Libevent检查：
解锁自己(线程)没有持有的锁在未解锁前，自己(线程)再次锁定一个非递归锁。Libevent通过一些变量记录锁的使用情况，当检查到这些锁的错误使用时，就调用abort，退出运行。
用户只需在调用evthread_use_pthreads或者evthread_use_windows_threads之后，调用evthread_enable_lock_debuging()函数即可开启调试锁的功能。该函数有一个拼写错误。在2.1.2-alpha版本中会改正为evthread_enable_lock_debugging，为了后向兼容，两者都会支持的。
现在看一下Libevent是锁调试功能。
[cpp] view plain copy //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。但实际上，使用的还是之前用户定制的线程锁操作函数，只是加多了一层抽象而已。如果看不懂这段话，可以看下面的代码，看完已经就会懂的了。
[cpp] view plain copy //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 结构体，它对锁的一些使用状态进行了记录。
现在看一下解锁时的检测。这主要是检测解锁一个自己没有锁定的锁，比如锁是由线程A锁定的，但线程B却去解锁。
[cpp] view plain copy //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。本来这个定制应该放在前一篇博客讲的。但由于其实现用到了调试锁的一些内容，所以就放到这里讲。
[cpp] view plain copy //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函数的实现：
[cpp] view plain copy //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是一个条件宏。 [cpp] view plain copy //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成员的赋值情况。
[cpp] view plain copy 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。
[cpp] view plain copy 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时，是可以取消线程锁功能的。可以尝试编译运行下面的代码。代码一运行就可以看到段错误了。
[cpp] view plain copy #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);完成这个断言。要注意的是：这个已锁断言要在开启了调试锁的前提下，才能使用的。
下面代码可以看到断言锁是怎么实现的：
[cpp] view plain copy 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
