This is the mail archive of the
mailing list for the pthreas-win32 project.
Re: Buggy conditions
- To: "Pthreads-Win32 Mailing List" <firstname.lastname@example.org>
- Subject: Re: Buggy conditions
- From: "Aurelio Medina" <email@example.com>
- Date: Wed, 30 Jun 1999 10:53:21 -0500
After revisiting the source code, I better understand the implementation of
condition variables now. The library does not provide a desired atomic
operation, but it does try to prevent deadlock using semaphores (I used
Win32 Events which would've caused deadlock). As soon as possible, I will
test this implementation using my Win32/UNIX applications which constantly
has about 2-20 threads communicating with each other and hope no problems
occur. I know that my code is well tested (i.e. in production use for well
over a year with no thread problems) and works with HP-UX and Solaris POSIX
Threads. It should provide a very good test case for the Win32 PThread
library since it makes use of condition variables, mutexes, thread
operations, and thread local storage. Is there any issues I should know of
before using this library or should it just work?
From: Peter Slacik <Peter.Slacik@tatramed.sk>
To: Medina, Aurelio <firstname.lastname@example.org>; Pthreads-Win32 Mailing List
Date: Thursday, June 24, 1999 9:46 AM
Subject: Re: Buggy conditions
>"Medina, Aurelio" wrote:
>> The pthread_cond_wait() function must unlock the mutex and wait for the
>> condition ATOMICALLY. If not, it is possible that after thread A
>> the mutex, thread B may acquire the mutex, change the condition variable,
>> and signal/broadcast the condition before thread A gets to wait for the
>Yes, the signaling thread (or another waiter) could be able to preempt the
>former waiter this way...
>> Thread A will be left waiting for a signal that might not get
>> regenerated and a condition variable that is set but can't get to because
>> its stuck in a wait state. Hence we have a deadlock condition.
>... but no deadlock condition should arise (with my modifications). In my
>opinion, the worst case would be that another thread which calls
>pthread_cond_wait() would wake up sooner. I hope that no wakeup should be
>> If the current PThreads library IS providing the mutex unlock and
>> wait in one atomic step somehow, then I misunderstood the source.
>Although requested by the POSIX threads standard, PThreads library does not
>provide this functionality correctly. Maybe "almost correctly"?