This is the mail archive of the mailing list for the pthreas-win32 project.

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

Re: Buggy conditions


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?


-----Original Message-----
From: Peter Slacik <>
To: Medina, Aurelio <>; 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
>> condition.
>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"?
>Peter Slacik

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