Merged revisions 105116 via svnmerge from

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r105116 | russell | 2008-02-28 16:23:05 -0600 (Thu, 28 Feb 2008) | 8 lines

Fix a bug in the lock tracking code that was discovered by mmichelson.  The issue
is that if the lock history array was full, then the functions to mark a lock as
acquired or not would adjust the stats for whatever lock is at the end of the array,
which may not be itself.  So, do a sanity check to make sure that we're updating
lock info for the proper lock.

(This explains the bizarre stats on lock #63 in BE-396, thanks Mark!)

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
Russell Bryant
2008-02-28 22:39:26 +00:00
parent f0379886c5
commit 7da06e6cb8
3 changed files with 20 additions and 16 deletions

View File

@@ -633,7 +633,7 @@ void ast_store_lock_info(enum ast_lock_type type, const char *filename,
pthread_mutex_unlock(&lock_info->lock);
}
void ast_mark_lock_acquired(void)
void ast_mark_lock_acquired(void *lock_addr)
{
struct thr_lock_info *lock_info;
@@ -641,11 +641,13 @@ void ast_mark_lock_acquired(void)
return;
pthread_mutex_lock(&lock_info->lock);
lock_info->locks[lock_info->num_locks - 1].pending = 0;
if (lock_info->locks[lock_info->num_locks - 1].lock_addr == lock_addr) {
lock_info->locks[lock_info->num_locks - 1].pending = 0;
}
pthread_mutex_unlock(&lock_info->lock);
}
void ast_mark_lock_failed(void)
void ast_mark_lock_failed(void *lock_addr)
{
struct thr_lock_info *lock_info;
@@ -653,8 +655,10 @@ void ast_mark_lock_failed(void)
return;
pthread_mutex_lock(&lock_info->lock);
lock_info->locks[lock_info->num_locks - 1].pending = -1;
lock_info->locks[lock_info->num_locks - 1].times_locked--;
if (lock_info->locks[lock_info->num_locks - 1].lock_addr == lock_addr) {
lock_info->locks[lock_info->num_locks - 1].pending = -1;
lock_info->locks[lock_info->num_locks - 1].times_locked--;
}
pthread_mutex_unlock(&lock_info->lock);
}