|
Home > Archive > Unix Programming > October 2004 > How to find out which threads are suspended on a specified pthread mutex with dbx?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to find out which threads are suspended on a specified pthread mutex with dbx?
|
|
| Kevin Ren 2004-10-31, 2:46 am |
| Could anybody tell me how to find out the following information when
debuging a program with dbx:
1) Which threads are suspended on a specified mutex?
2) Which thread has acquired the mutex?
Here is a small program through which I observed the the value of g_mtx.
Bx stands for breakpoint.
#include <unistd.h>
#include <pthread.h>
pthread_mutex_t g_mtx = PTHREAD_MUTEX_INITIALIZER;
void * thr_entr( void *dummy )
{
B1=> pthread_mutex_lock( &g_mtx );
sleep(1);
B2=> pthread_mutex_unlock( &g_mtx );
return NULL;
}
int main( int argc, char *argv[] )
{
pthread_t tid;
B3=> pthread_mutex_lock( &g_mtx );
pthread_create( &tid, NULL, thr_entr, NULL );
sleep(30);
B4=> pthread_mutex_unlock( &g_mtx );
pthread_join(tid, NULL);
return 0;
}
After started, the program's execution path is B3->B1->B4->B2.
The g_mtx's value is changed as follows:
Before B3:
g_mtx = {
__pthread_mutex_flags = {
__pthread_mutex_flag = ""
__pthread_mutex_type = 0
}
__pthread_mutex_lock = {
__pthread_mutex_lock64 = {
__pthread_mutex_pad = ""
}
__pthread_mutex_owner64 = 0
}
__pthread_mutex_data = 0
}
After B3 and before B1:
g_mtx = {
__pthread_mutex_flags = {
__pthread_mutex_flag = ""
__pthread_mutex_type = 0
}
__pthread_mutex_lock = {
__pthread_mutex_lock64 = {
__pthread_mutex_pad = ""
}
__pthread_mutex_owner64 = 4278190080ULL
}
__pthread_mutex_data = 134016ULL
}
After B1 and before B4:
g_mtx = {
__pthread_mutex_flags = {
__pthread_mutex_flag = ""
__pthread_mutex_type = 19800U
}
__pthread_mutex_lock = {
__pthread_mutex_lock64 = {
__pthread_mutex_pad = ""
}
__pthread_mutex_owner64 = 4278190081ULL
}
__pthread_mutex_data = 134016ULL
}
After B4 before B2:
g_mtx = {
__pthread_mutex_flags = {
__pthread_mutex_flag = ""
__pthread_mutex_type = 19800U
}
__pthread_mutex_lock = {
__pthread_mutex_lock64 = {
__pthread_mutex_pad = ""
}
__pthread_mutex_owner64 = 4278190080ULL
}
__pthread_mutex_data = 4279762368ULL
}
And after B2:
g_mtx = {
__pthread_mutex_flags = {
__pthread_mutex_flag = ""
__pthread_mutex_type = 19800U
}
__pthread_mutex_lock = {
__pthread_mutex_lock64 = {
__pthread_mutex_pad = ""
}
__pthread_mutex_owner64 = 0
}
__pthread_mutex_data = 0
}
I am interested in value of mutex after B1 before B4. At this point, main
thread acquired the mutex,
and the thread thr_entr was suspended on the g_mtx. My question is, how the
value of g_mtx reflect
this fact?
Thanks,
Kevin
| |
| Paul Pluzhnikov 2004-10-31, 5:49 pm |
| "Kevin Ren" <hren@lucent.com> writes:
> Could anybody tell me how to find out the following information when
> debuging a program with dbx:
Not without knowing what OS you are on.
> 1) Which threads are suspended on a specified mutex?
> 2) Which thread has acquired the mutex?
On Solaris, try "help syncs". Here is a trace from Studio 8 on
Solaris 9 (this did not work for me on Solaris 7 using the same dbx):
(dbx) run
Running: a.out
(process id 6623)
t@1 (l@1) stopped in main at line 19 in file "junk.c"
19 pthread_create( &tid, NULL, thr_entr, NULL );
(dbx) syncs
All locks currently known to libthread:
__environ_lock (0x00020cc8): thread mutex(unlocked)
g_mtx (0x00020cf8): thread mutex(locked)
.... other locks omitted ...
(dbx) sync -info 0x00020cf8
g_mtx (0x20cf8): thread mutex(locked)
Lock owned by t@1
No threads are blocked by this lock
> My question is, how the value of g_mtx reflect this fact?
That's an implementation detail that (in theory) can change between
subminor revisions of libpthread.so. Note that the contents of
g_mtx is different between Solaris 7 and 9.
Decoding this info is best left to libthread_db.so.1 (which dbx uses
in the "sync -info"). I suspect this doesn't work on my Solaris 7
box because my libthread_db.so.1 and libthread.so.1 are "out of sync".
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Kevin Ren 2004-10-31, 8:46 pm |
| Hi Paul,
My OS is Solaris 7.
Your reply is helpful.
Thank you very much for your help.
Kevin
"Paul Pluzhnikov" <ppluzhnikov-nsp@charter.net> wrote in message
news:m3u0sabuij.fsf@salmon.parasoft.com...
> "Kevin Ren" <hren@lucent.com> writes:
|
|
|
|
|