RE: Buggy conditions

["Bossom, John" <John.Bossom@Cognos.COM>]

Before making tweeks and changes with regards to
the implementation of the pthread condition variables,
please thoroughly read the following paper by
Professor Douglas Schmidt, from which this implementation
was derived. Professor Schmidt, from Washington University,
heads up the ACE (Adaptive Communication Environment) project.

This paper discusses the issues with regards to implementing
pthread condition variables on Win32.

http://www.cs.wustl.edu/~schmidt/win32-cv-1.html

John.

-----Original Message-----
From: Peter Slacik [mailto:Peter.Slacik@tatramed.sk]
Sent: Thursday, June 24, 1999 10:45 AM
To: Medina, Aurelio; Pthreads-Win32 Mailing List
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 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