Unix Programming - How to find out which threads are suspended on a specified pthread mutex with dbx?

Author

How to find out which threads are suspended on a specified pthread mutex with dbx?

Kevin Ren

2004-10-31, 3:56 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, 3:56 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:56 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:

Sponsored Links