This is the mail archive of the pthreads-win32@sourceware.cygnus.com 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


"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








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