Libevent-2.1.8源码分析——锁和线程

1. 概述

libevent作为一个开源的高性能的事件通知库。经常被用作于多线程网络程序的开发。说到多线程我们想到的当然是线程安全。庆幸的是libevent是支持多线程的（默认情况下是不开启多线程的）。当我们调用 int evthread_use_windows_threads(void) 、int evthread_use_pthreads(void)或int evthread_set_condition_callbacks(const struct evthread_condition_callbacks *)则就开启了多线程的支持。

libevent的结构体在多线程下通常有三种工作方式：

• 某些结构体只能使用在单线程：同时在多个线程中使用它们总是不安全的。
• 某些结构具有可选择的锁： 可以告知libevent是否需要在多个线程中使用每个对象。
• 某些结构体总是锁定的：如果libevent在支持锁的配置下运行，在多线程中使用它们总是安全的。

关于libevent锁和线程的说明：libevent的内部实现不需要多线程，为此我们在libevent的源码中也看不到有关线程的接口。多线程的使用无非就是在应用程序（比如说某个网络应用程序）上，既然libevent内部不会使用到线程，那么也就不需要相关的线程接口（如果说需要向libevent中注册线程使用的接口，在调用libevent线程接口，就显得多此一举，应该也没人这么做）。但是我们很有可能在某个多线程程序中使用libevent，那么就需要保证libevent中的某些结构体是线程安全的，为此libevent提供了锁和条件变量来确保线程的同步。

2. 锁和条件变量

和之前讨论的日志或内存管理类似，libevent运行我们定制自定义的锁和条件变量通过使用evthread_set_condition_callbacks，或者使用libevent针对Windows锁和条件变量的封装。Linux（Unix）锁和条件变量的封装。分别是evthread_use_windows_thread和evthread_use_pthreads，后面我们会提到。

先来看看对应的锁结构：

struct evthread_lock_callbacks {//锁的API版本号，通常是宏EVTHREAD_LOCK_API_VERSIONint lock_api_version;//锁的类型：EVTHREAD_LOCKTYPE_RECURSIVE and EVTHREAD_LOCKTYPE_READWRITEunsigned supported_locktypes;//用于分配和构造类型为supported_locktypes的锁void *(*alloc)(unsigned locktype);//用于释放类型为supported_locktypes的锁void (*free)(void *lock, unsigned locktype);//加锁，成功返回0，失败返回非0int (*lock)(unsigned mode, void *lock);//解锁，成功返回0，失败返回非0int (*unlock)(unsigned mode, void *lock);};

再来看看对应的条件变量结构：

struct evthread_condition_callbacks {//锁的API版本号，通常是宏EVTHREAD_CONDITION_API_VERSIONint condition_api_version;//用于分配和构造一个条件变量，这个版本的condtype为0void *(*alloc_condition)(unsigned condtype);//用于释放该条件变量void (*free_condition)(void *cond);//唤醒等待线程，如果broadcast为1，则唤醒所有等待线程，否则值唤醒一个等待线程int (*signal_condition)(void *cond, int broadcast);//等待条件变量变为真，如果timeout为NULL则无限等待，否则等待timeout时间，该函数调用将持有锁int (*wait_condition)(void *cond, void *lock,    const struct timeval *timeout);};

看到这里，相信对应POSIX的互斥量和条件变量熟悉的人来说，就不会很陌生了。当然可以参考我的另外2篇博客互斥量和条件变量。

接下来我们在说说锁的类型，

在头文件thread.h中定义了两个宏，用来表示不同的锁类型

/** A recursive lock is one that can be acquired multiple times at once by the * same thread.  No other process can allocate the lock until the thread that * has been holding it has unlocked it as many times as it locked it. */#define EVTHREAD_LOCKTYPE_RECURSIVE 1/* A read-write lock is one that allows multiple simultaneous readers, but * where any one writer excludes all other writers and readers. */#define EVTHREAD_LOCKTYPE_READWRITE 2

• supported_locktypes为0，那么表示是一个普通的互斥量。
  
• supported_locktypes为EVTHREAD_LOCKTYPE_RECURSIVE，那么表示为一个递归锁。
  
• supported_locktypes为EVTHREAD_LOCKTYPE_READWRITE，那么表示为一个读写锁。
  

对于上面三种锁类型，可以参考POSIX的互斥量和读写锁。对于不清楚递归锁和非递归锁的可以另行查找相关资料，这边就不多说了。

对于自定义我们自己的锁和条件变量可以调用下面2个接口：

int evthread_set_lock_callbacks(const struct evthread_lock_callbacks *);int evthread_set_condition_callbacks(const struct evthread_condition_callbacks *);

这边为了方便，只对其中一个进行分析。就以锁的来分析。

intevthread_set_lock_callbacks(const struct evthread_lock_callbacks *cbs){struct evthread_lock_callbacks *target = evthread_get_lock_callbacks();#ifndef EVENT__DISABLE_DEBUG_MODEif (event_debug_mode_on_) {if (event_debug_created_threadable_ctx_) {    event_errx(1, "evthread initialization must be called BEFORE anything else!");}}#endifif (!cbs) {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;}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;}}

事实上实现上很简单，就是将自定义的struct evthread_lock_callbacks结构，拷贝到一个全局变量中去。当然这里面还区分debug锁和非debug锁。

如果不想自己再去自定义锁和条件变量，那么libevent也为我们封装了window和Linux上的锁和条件变量，我们只需要调用evthread_use_windows_threads或evthread_use_pthreads接口即可。

我们来看看evthread_use_pthreads。

intevthread_use_pthreads(void){struct evthread_lock_callbacks cbs = {EVTHREAD_LOCK_API_VERSION,EVTHREAD_LOCKTYPE_RECURSIVE,evthread_posix_lock_alloc,evthread_posix_lock_free,evthread_posix_lock,evthread_posix_unlock};struct evthread_condition_callbacks cond_cbs = {EVTHREAD_CONDITION_API_VERSION,evthread_posix_cond_alloc,evthread_posix_cond_free,evthread_posix_cond_signal,evthread_posix_cond_wait};/* Set ourselves up to get recursive locks. */if (pthread_mutexattr_init(&attr_recursive))return -1;if (pthread_mutexattr_settype(&attr_recursive, PTHREAD_MUTEX_RECURSIVE))return -1;evthread_set_lock_callbacks(&cbs);evthread_set_condition_callbacks(&cond_cbs);evthread_set_id_callback(evthread_posix_get_id);return 0;}

里面有libevent帮我们封装好的锁和条件变量。这些封装就是POSIX的锁和条件变量的知识了，不在多说。不过这里并不支持读写锁，如果有需要的话需要自己封装。

3. 调试锁

为了帮助我们进行锁的使用，libevent提供了一个可选的“锁调试”特征。这个特征包装了锁调用，以便捕获典型的锁错误。开启调试锁需要在调用evthread_use_windows_threads或evthread_use_pthreads或自定义锁和条件变量的接口后，调用evthread_enable_lock_debugging。

典型的锁错误包括：

• 解锁没有持有的锁
• 重新锁定一个非递归锁

如果发生这些错误中的某一个libevent将断言失败，中断程序输出日志，帮助我们查找锁错误。

先来看看evthread_enable_lock_debugging函数:

voidevthread_enable_lock_debugging(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;memcpy(&original_lock_fns_, &evthread_lock_fns_,    sizeof(struct evthread_lock_callbacks));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_debugging_enabled_是个全局变量，当我们调用了evthread_enable_lock_debugging接口则evthread_lock_debugging_enabled_被置为1，表示使能了调试锁。
在来看看original_lock_fns_和evthread_lock_fns_是什么？

/* globals */GLOBAL int evthread_lock_debugging_enabled_ = 0;GLOBAL struct evthread_lock_callbacks evthread_lock_fns_ = {0, 0, NULL, NULL, NULL, NULL};GLOBAL unsigned long (*evthread_id_fn_)(void) = NULL;GLOBAL struct evthread_condition_callbacks evthread_cond_fns_ = {0, NULL, NULL, NULL, NULL};/* Used for debugging */static struct evthread_lock_callbacks original_lock_fns_ = {0, 0, NULL, NULL, NULL, NULL};static struct evthread_condition_callbacks original_cond_fns_ = {0, NULL, NULL, NULL, NULL};

original_lock_fns_用于保存在调用evthread_enable_lock_debugging之前的锁，evthread_lock_fns_则更新为调试锁。
然后，我们分析下debug_lock_alloc:

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->signature = DEBUG_LOCK_SIG;result->locktype = locktype;result->count = 0;result->held_by = 0;return result;}

事实上，上述的代码分析起来也简单，现在original_lock_fns_实际上就是我们自定义的锁结构了，debug锁使用还是之前我们自定义的锁函数分配的。

struct debug_lock {unsigned signature;//debug_lock签名unsigned locktype;//锁的类型unsigned long held_by;//线程id，表示哪个线程持有锁/* XXXX if we ever use read-write locks, we will need a separate * lock to protect count. */int count;//锁的引用计数void *lock;//对应的锁结构};

再来看看debug_lock_lock这个接口：

static intdebug_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));elseEVUTIL_ASSERT((mode & (EVTHREAD_READ|EVTHREAD_WRITE)) == 0);if (original_lock_fns_.lock)res = original_lock_fns_.lock(mode, lock->lock);if (!res) {evthread_debug_lock_mark_locked(mode, lock);}return res;}

实际上还是调用自定义的锁函数，只是多了检查如果锁失败。

static voidevthread_debug_lock_mark_locked(unsigned mode, struct debug_lock *lock){EVUTIL_ASSERT(DEBUG_LOCK_SIG == lock->signature);++lock->count;if (!(lock->locktype & EVTHREAD_LOCKTYPE_RECURSIVE))EVUTIL_ASSERT(lock->count == 1);if (evthread_id_fn_) {unsigned long me;me = evthread_id_fn_();if (lock->count > 1)EVUTIL_ASSERT(lock->held_by == me);lock->held_by = me;}}

当锁失败之后，会先进行引用计数的增加，如果是非递归锁，则进行断言。必须满足引用计数为1.不满足则进行日志输出，并终止程序。如果满足，那么就进行线程ID的断言，实际上evthread_id_fn是个可设置的线程id获得的函数指针。当锁被持有时，需要判断加锁的线程是否就是持有锁的线程（其实就是递归锁）。
最后我们在来看看解锁：

static intdebug_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;}

解锁也相对简单，evthread_debug_lock_mark_unlocked这个之后再看，其实也就是调用 我们定制的解锁。

static voidevthread_debug_lock_mark_unlocked(unsigned mode, struct debug_lock *lock){EVUTIL_ASSERT(DEBUG_LOCK_SIG == lock->signature);if (lock->locktype & EVTHREAD_LOCKTYPE_READWRITE)EVUTIL_ASSERT(mode & (EVTHREAD_READ|EVTHREAD_WRITE));elseEVUTIL_ASSERT((mode & (EVTHREAD_READ|EVTHREAD_WRITE)) == 0);if (evthread_id_fn_) {unsigned long me;me = evthread_id_fn_();EVUTIL_ASSERT(lock->held_by == me);if (lock->count == 1)lock->held_by = 0;}--lock->count;EVUTIL_ASSERT(lock->count >= 0);}

根据锁的类型进行断言读写锁或递归锁，再判断调用解锁的是否是持有锁的线程，以及进行引用计数的处理。
上面就是对libevent中锁进行简要的分析，当然不是很详细。

4. 源码中的使用

在libevent中我最先看的sample是 time-test.c。在这个例子里面event_add，就是事件的添加了。对于在多线程的环境下，进行事件的添加，毫无疑问是需要进行保护的，那么这个接口的实现就会进行加锁来保证线程安全。

intevent_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_nolock_(ev, tv, 0);EVBASE_RELEASE_LOCK(ev->ev_base, th_base_lock);return (res);}

果不其然，从源码中我们就可以知道EVBASE_ACQUIRE_LOCK进行加锁，EVBASE_RELEASE_LOCK进行解锁。这两个都是宏。

先来看看EVBASE_ACQUIRE_LOCK：

如果没有使能多线程支持，那么就什么都不处理：

#define EVUTIL_NIL_STMT_ ((void)0)#define EVBASE_ACQUIRE_LOCK(base, lock) EVUTIL_NIL_STMT_#define EVBASE_RELEASE_LOCK(base, lock) EVUTIL_NIL_STMT_

如果使能多线程支持：

/** Lock an event_base, if it is set up for locking.  Acquires the lock    in the base structure whose field is named 'lockvar'. */#define EVBASE_ACQUIRE_LOCK(base, lockvar) do {\EVLOCK_LOCK((base)->lockvar, 0);\} while (0)

里面还是个宏。

如果没有使能锁：

#define EVUTIL_NIL_STMT_ ((void)0)#define EVLOCK_LOCK(lockvar, mode) EVUTIL_NIL_STMT_

在window上：

/** Acquire a lock. */#define EVLOCK_LOCK(lockvar,mode)\do {\if (lockvar)\evthreadimpl_lock_lock_(mode, lockvar);\} while (0)

在Linux/Unix上：

/** Acquire a lock. */#define EVLOCK_LOCK(lockvar,mode)\do {\if (lockvar)\evthread_lock_fns_.lock(mode, lockvar);\} while (0)

本人对linux上的比较熟悉，就以Linux上作为分析。

实际上就是我们自定义的lock函数了。解锁差不多，就不在重复了。

5. 总结

虽然并没有很详细的进行分析，可能还有一些理解错误的地方，但是对于libevent的锁和线程的分析算是告一段落了。