Mail Archives: cygwin/2001/06/21/14:06:30
Actually, I think your solution here is the right one... I'm sending in
a patch based on it.
Rob
----- Original Message -----
From: "Greg Smith" <gsmith AT nc DOT rr DOT com>
To: <cygwin AT cygwin DOT com>
Sent: Thursday, June 21, 2001 3:11 PM
Subject: 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
>
>
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -