Debugging threads with HP Wilde Beest

}
The following command enables you to check this condition in a threaded application.
(gdb) set thread-check cv-multiple-mxs[on|off]
The debugger transfers the execution control to the user and prints a warning message
when this condition is detected.
The following is a segment of the HP WDB output:
Starting program: /home/gdb/enh_thr_cv_multiple_mxs bad
[Switching to thread 4 (system thread 39531)]
warning: Attempt to associate condition variable 0 with mutexes 1 and 2.
0x800003ffeffcc608 in __rtc_pthread_dummy+0 () from ../librtc64.sl
According to pthread implementation, the threads that concurrently wait on a single
conditional variable need to specify the same associated mutex.
TIP: The solution is to correct the application source code in such a way that the
condition variable which violates the rule uses the same mutex.
Problem: The thread terminates execution without unlocking the associated mutexes or read-write
locks.
Consider the following scenario:
Thread A holds mutex MX. This thread terminates without unlocking the mutex MX.
There are other threads in the program that wait to gain control on MX.
The termination of thread A with the locked mutex MXcauses the other threads to be
in an endless wait to gain control on MX. This situation is an example of a deadlock
where the program execution is dependent on the locked mutex and hence is unable
to proceed.
Consider the following example enh_thr_exit_own_mx.c
#include pthread.h
#include stdlib.h
#include errno.h
pthread_mutex_t job_lock1 = PTHREAD_MUTEX_INITIALIZER;
extern void fatal_error(int err, char *f);
void
producer_thread(pthread_mutex_t* job_lock)
{
int ret_val;
/* Acquire the associated mutex lock */
if ((ret_val = pthread_mutex_lock(job_lock)) != 0)
fatal_error(ret_val, "p mtx_lock failed");
}
#define check_error(return_val, msg) { \
Modes of Thread debugging in HP WDB 29