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

川长思鸟来 2022-05-09 06:06 307阅读 0赞

# 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。本来这个定制应该放在[前一篇博客][Link 1]讲的。但由于其实现用到了调试锁的一些内容，所以就放到这里讲。

//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][http_www.wangafu.net_nickm_libevent-book_Ref1_libsetup.html]

[Link 1]: http://blog.csdn.net/luotuo44/article/details/38350633
[http_www.wangafu.net_nickm_libevent-book_Ref1_libsetup.html]: http://www.wangafu.net/~nickm/libevent-book/Ref1_libsetup.html