This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Deadly embrace between pthread_cond_wait and pthread_cond_signal


I am using the cygwin-src snapshot from June 19.

Suppose I have a thread, t1, that looks like:
void *t1() {
   pthread_mutex_lock(&lock);
   pthread_cond_wait(&cond,&lock);
   pthread_mutex_unlock(&lock);
}
and a thread, t2, that looks like:
void *t2() {
   pthread_mutex_lock(&lock);
   pthread_cond_signal(&cond);
   sleep(1);
   pthread_cond_signal(&cond);
   pthread_mutex_unlock(&lock);
}

When thread t1 wakes up as a result of the first pthread_cond_signal
issued by thread t2, __pthread_cond_wait in thread.cc obtains internal
mutex `cond_access' then hangs trying to acquire external mutex `lock'
which is owned by thread t2.

When thread t2 issues the second pthread_cond_signal, still holding
external mutex `lock', pthread_cond::Signal in thread.cc tries to
get internal mutex `cond_access' and hangs because it is owned by t1.

So, t1 has `cond_access' and is waiting on `lock' 
and t2 has `lock' and is waiting on `cond_access'.

As a workaround, I moved the pthread_mutex_lock for cond_access in
__pthread_cond_wait from before the (*cond)->mutex->Lock() to after
it, and my application has gotten a whole lot further than ever before
using native cygwin pthreads, although it does seem to be running as
slow as molasses compared to linux.  But maybe that's cause of my
debug stuff I had to add.

Thanks,

Greg

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]