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

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

"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.

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: