This is the mail archive of the
pthreads-win32@sourceware.cygnus.com
mailing list for the pthreas-win32 project.
Re: Buggy conditions
- To: "Medina, Aurelio" <aureliom@crt.com>, Pthreads-Win32 Mailing List <pthreads-win32@sourceware.cygnus.com>
- Subject: Re: Buggy conditions
- From: Peter Slacik <Peter.Slacik@tatramed.sk>
- Date: Thu, 24 Jun 1999 16:44:43 +0200
- Organization: TatraMed s.r.o.
- References: <F931488C3634D11180D700A02461E2450149E3EF@chitmd03.nt.il.nbgfn.com>
"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 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.
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 lost.
> If the current PThreads library IS providing the mutex unlock and condition
> 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