Debugging threads with HP Wilde Beest

NOTE: In some rare predictable situations the thread might attempt to unlock an

object that it has no control over. For example, an application which instructs the thread

to unlock a mutex when it encounters a C++ destructor, irrespective of the history of

the processing of the C++ constructor.

Problem: The Thread waits on a mutex or a read-write lock that is held by a thread with a different

scheduling policy

Consider the following scenario:

Thread 1 is scheduled using Policy1, SP1. Thread 2 is scheduled using Policy2, SP2.

Thread 1 waits for a read-write lock object which is held by Thread 2. Since the

scheduling policy of the threads is not the same, there are chances of delay in Thread

2 releasing the lock for the read-write object.

Consider the following example enh_thr_mixed_sched.c:

#include pthread.h

#include errno.h

#include sched.h

#include stdio.h

extern void *thread1_func(), *thread2_func();

extern void fatal_error(int err_num, char *func);

pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;

/* Print error information, exit with -1 status. */

void

fatal_error(int err_num, char *function)

{

char *err_string;

err_string = strerror(err_num);

fprintf(stderr, "%s error: %s\n", function, err_string);

exit(-1);

}

#define check_error(return_val, msg) { \

if (return_val != 0) \

fatal_error(return_val, msg); \

}

void *

thread1_func()

{

int ret_val;

ret_val = pthread_mutex_lock(&mtx);

check_error(ret_val, "mutex_lock mtx");

printf("In thread1_func()\n");

sleep(5);

ret_val = pthread_mutex_unlock(&mtx);

check_error(ret_val, "mutex_unlock mtx");