Subj : Re: Unexplained race condition with POSIX threads
To   : comp.programming.threads,comp.sources.d
From : ptjm
Date : Tue Mar 29 2005 05:55 am

In article <42489852$1@olaf.komtel.net>,
Malte Starostik  <malte@starostik.de> wrote:
% usenet@sta.samsung.com schrieb:

% >     pthread_mutexattr_t attr;
% >     pthread_mutexattr_init(&attr);
% >     attr.__mutexkind = PTHREAD_MUTEX_RECURSIVE_NP;
% > 
% >     // Initialize the mutex
% >     pthread_mutex_init(&m_mutex,&attr);
% simpler alternative:
% m_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;

I'm not sure why you're both so keen to use non-portable constructs,
but the use of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is certainly
wrong here since mutex initializers are only defined to work on
static mutexes. If you must have a recursive mutex, why not set
it up portably?

 pthread_mutexattr_t attr;
 pthread_mutexattr_init(&attr);
 pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
 pthread_mutex_init(&m_mutex, &attr);
 pthread_mutexattr_destroy(&attr);

% >       // Wait on the condition variable
% >       if(pthread_cond_wait(&m_condition, &m_mutex))

I can't be bothered to wade through all this, but the OP's
problem is almost certainly in the way this condition
wait is set up. The code seems to be structured like this

  do something
  wait for the cv

but it ought to be structured like this

  while there's nothing to do
    wait for the cv

  do something

The deadlock is almost certainly because the CV was signalled some time
when the waiting thread wasn't actually in a condition wait.

-- 

Patrick TJ McPhee
North York  Canada
ptjm@interlog.com

.