转载请注明出处: http://blog.csdn.net/luotuo44/article/details/38360525
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 结构体,它对锁的一些使用状态进行了记录。
//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; //记录这个锁是被哪个线程所拥有 } }
现在看一下解锁时的检测。这主要是检测解锁一个自己没有锁定的锁,比如锁是由线程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函数之前。如果允许修改锁定制的线程锁,那么将可能发生,加锁和解锁操作是完全不同的两套线程锁。
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); }
//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中,很多线程安全的函数都会调用一个已加锁断言。确保在进入这函数的时候,已经获得了一个锁。一般是调用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