Subj : Re: Unexplained race condition with POSIX threads To : comp.programming.threads,comp.sources.d From : Malte Starostik Date : Tue Mar 29 2005 08:52 am Patrick TJ McPhee schrieb: > 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); Duh! Now I know what the _NP prefix means...just checked the man page and it states so, but then I rarely ever used pthreads directly. Plus man pthread_mutexattr_settype *only* lists the _NP ones, but not the non-_NP variants :-( OTOH, I fail to see why the OP needs a recursive mutex at all, but maybe that's just due to stripping it down to the given example. > > % > // 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. I first thought so. But the thread (from looking, didn't try to compile or run it) will always end up in the condition wait after finishing all the work for lack of any termination condition. Either there are still entries in the activation list before waiting or the thread will be waiting for it when condition is signalled. The only varying factor is the contents of the list when dumped to stdout, IMBW. Cheers, Malte .