Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3B3181E5.E6F0D06A@nc.rr.com> Date: Thu, 21 Jun 2001 01:11:01 -0400 From: Greg Smith X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Deadly embrace between pthread_cond_wait and pthread_cond_signal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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