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

最新推荐文章于 2023-08-08 09:32:12 发布

amoscykl

最新推荐文章于 2023-08-08 09:32:12 发布

阅读量264

点赞数

分类专栏： Libevent Libevent 文章标签： libevent

Libevent 同时被 2 个专栏收录

23 篇文章 3 订阅

订阅专栏

Libevent

23 篇文章 7 订阅

订阅专栏

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