Mail Archives: cygwin/2002/05/01/08:24:22
> -----Original Message-----
> From: Michael Beach [mailto:michaelb AT ieee DOT org]
> Sent: Wednesday, May 01, 2002 9:44 PM
> To: cygwin AT cygwin DOT com
> Subject: 1.1.3 and upwards: apparent bug with
> pthread_cond_wait() and/or signal()
>
>
> Hi all, I've just been wrestling with some code I've been
> writing, trying to
> get pthreads condition variables to work under Cygwin on
> Windows 2000. I've
> tried DLL versions 1.1.3 and the 20020409 snapshot, and
> neither are working
> for me, so I'm assuming that no versions in between will work
> either...
Between 1.1.3 and 1.3.0 a huge change occurred in the pthreads code
base, so this assumption is not safe. (It's not necessarily wrong
either.) I'd definitely be using 1.3.10 though.
> #include <pthread.h>
> #include <iostream>
The cygwin c++ libgcc, stdlibc++ and gcc are not built with thread
support, so C++ and threads may not work well together. C should work
fine, and if anyone convinces Chris to release a thread-enabled gcc, C++
should get better.
>
>
> int main(int argc, char *argv[])
>
> {
>
> CondVarTestData td;
>
> pthread_mutex_init(&td.m, 0);
>
> pthread_cond_init(&td.cv, 0);
>
> td.state = CondVarTestData::START;
>
> pthread_t th;
>
> pthread_create(&th, 0, condVarTestThreadEntry, &td);
>
> {
>
> pthread_mutex_lock(&td.m);
you should lock this before starting your thread. It's a potential race.
And due to cygwin's implementation, it *is* racing, and your other
thread is entering the mutex and signalling before you enter the mutex
and wait. That early signal with no waiters gets lost (as it should).
You should also _always_ test for the return value when using pthreads
calls. They don't throw exceptions and they don't set errno, so the only
way you can tell an error has occurred is to record the return value.
Rib
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -