> The PtCondTimedWait() seems to be working correctly.  I don't understand why 
> since it appears to be doing the same thing as the pthread_cond_timed() 
> function.

Not exactly: the pthread function unlocks a mutex when going to sleep.  The Pt function unlocks the Photon library.  
Unlocking the Photon library is what allows the PtEnter() in the other thread to come through.

> When you mentioned checking for spurious wakeups before, can you elaborate a 
> little?

This is what POSIX says about it:

<QUOTE src="http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_timedwait.html">
When using condition variables there is always a Boolean predicate involving shared variables associated with each 
condition wait that is true if the thread should proceed. Spurious wakeups from the pthread_cond_timedwait() or 
pthread_cond_wait() functions may occur. Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not 
imply anything about the value of this predicate, the predicate should be re-evaluated upon such return.
</QUOTE>

In other words, pthread_cond_wait() may sometimes return zero even though nobody has signalled the condvar (yet).  
That's why it's important to have a separate variable to confirm that the wakeup was intentional; and it also makes it 
important to lock the mutex in the signalling thread, to protect your variable and to ensure that you don't signal the 
condvar before the other thread calls wait.

(If nobody is waiting on a condvar when you signal it, the signal is a no-op.  The signal doesn't get saved to 
immediately wake up the next wait call.  If you call cond_wait() after the signal(), you'll end up sleeping forever or 
until you time out.)
 
> Would I just need to check the return code to see why it returned to make sure
>  it was why I was expecting it to return?

No, because a return code of zero doesn't necessarily mean that signal was called.

> > The PatComSendMessageW() is called from a function that is a callback for a 
> > PtButton widget. 

Right, and therefore it is called with the Photon library locked.  You'll need to call either PtLeave() and then 
PtEnter(), or PtCondWait(), to temporarily unlock it and let the other thread's PtEnter() come through.
 
> > So, the user clicks the [Logon] button and the callback calls this function 
> to
> >  send the logon credentials to the database.
> > 
> > I don't have the PatComRecvMessage() set the mutex because I am not trying 
> to 
> > protect any shared memory, I just want my main thread to wait until a logon 
> 
> > response is returned from the database.  The callback signals that the 
> > condition is complete when that happens.
> > 
> > I didn't know about PtCondWait or PtCondTimedWait.  I will look at those.
> > 
> > Thanks for the information!
> > 
> > Kendall
> > 
> > > What calls PatComSendMessageW()?  Is it by any chance some sort of a 
> Photon 
> > 
> > > callback that runs with the Photon library locked?  If that's the case, 
> then
> >  
> > > PatComRecvMessage() in the other thread is getting stuck in its PtEnter() 
> 
> > call
> > > .
> > > 
> > > Also, PatComRecvMessage() seems to signal the condvar without locking 
> > > g_Read_Mutex.  How do you make sure that the pthread_cond_signal() doesn't
>  
> > > happen before PatComSendMessageW() calls pthread_cond_timedwait()?  Also, 
> 
> > you 
> > > don't seem to be doing anything about spurious wakeups -- is that 
> something 
> > 
> > > you're planning to add later?
> > > 
> > > Have you considered using PtCondWait() or PtCondTimedWait() instead of 
> > > pthread_cond_timedwait(), and the...