This is the mail archive of the
mailing list for the pthreas-win32 project.
RE: Buggy conditions
- To: "'Peter Slacik'" <Peter.Slacik@tatramed.sk>, Pthreads-Win32 Mailing List <firstname.lastname@example.org>
- Subject: RE: Buggy conditions
- From: "Medina, Aurelio" <email@example.com>
- Date: Wed, 23 Jun 1999 13:17:12 -0500
First of all, I have just begun to use this Win32 PThreads library and at
this time I do not have a full understanding of its implementation. Before
finding this library I had built my own simpler version of Pthreads for
WinNT. Since I am currently using condition variables in my application I
looked into this issue. Here is my observation:
The pthread_cond_wait() function must unlock the mutex and wait for the
condition ATOMICALLY. If not, it is possible that after thread A unlocks
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. 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.
In my implementation I used the Win32 SignalObjectAndWait() (available on
WinNT 4.0 only) function to provide the necessary operation. It provides
the ability to unlock a mutex and wait for an event in one atomic operation.
However, since the function takes only one wait object, I was only able to
implement pthread_cond_broadcast(). I like the effort put into this
library, which I must say is much farther along than mine, so I'll look into
a possible fix for this. I first have to get familiar with the source code.
If the current PThreads library IS providing the mutex unlock and condition
wait in one atomic step somehow, then I misunderstood the source.
I have ported the pthread_rwlock_*() library and the POSIX Message Queue
(e.g. mq_open()) library to WinNT. This code is almost entirely based on W.
Richard Stevens code from the book UNIX Network Programming Vol. 2. Is
anyone interested in making this part of the Win32 Pthreads Library?
Distributed Systems Management
Voice: (312) 234-2105
Fax: (312) 453-2105
From: Peter Slacik [SMTP:Peter.Slacik@tatramed.sk]
Sent: Wednesday, June 23, 1999 11:54 AM
To: Pthreads-Win32 Mailing List
Subject: Buggy conditions
I've got problems with code which uses pthread_cond_timedwait() +
pthread_cond_broadcast(). Sometimes threads deadlocks locking all
the same mutex
(bound to the condition variable).
It seems that if thread wakes up due to the timeout, it omits to
check whether the
condition variable was broadcasted concurrently. The waiter returns,
signaling thread waits on cv->waitersDone event to be set. If the
which decrements cv->waiters, timed out in _pthread_sem_timedwait(),
((result=errno)==0) is false and cv->waitersDone is never set. The
attempts to lock external mutex, locked by the broadcasting thread.
Additionally, it turned out that cv's data is not protected enough,
cv->waiters may be decremented by thread waked up after timeout and
thread wishing to wait at the same time. Therefore cv->waitersLock
Just working around... I'm sorry to post untested code, I have no
compile my attempt today to check it's correctness.
One question more: What happens, if thread waits on semaphore
object, wakes up
after timeout and then another (broadcasting) thread posts the
another thread will spuriously wake up next time, nothing more. Can
his/her opinion to this?
<< File: condvar.c.diff >>