Problem with pthread_cond_timedwait().

[Ross Johnson]

This is the same problem as reported several months ago by
Paul Joseph - see

http://sources.redhat.com/ml/pthreads-win32/2002/msg00038.html

Nir's description is pretty accurate.

This is a fairly critical bug now, so any help would really be 
appreciated.

At the time, I attempted to locate the problem but failed and 
haven't looked at it since. Here's what I found at the time by 
modifying and running Paul's test code:

	... running on a single CPU machine under Windows 98.

	- it hasn't hung when there are only one send and
	  receive thread;
	
	- there is no mutex deadlock occuring (i.e. same
	  thread attempting to lock the mutex twice). That
	  can be seen by looking at the code, but it was
	  confirmed by using errorcheck mutexes;
	
	- it's not compiler dependent. Both MSVC and GNU C
	  versions hang;
	
	- it's random;
	
	- the process doesn't hang, but all threads appear
	  to block;
	
	- all send threads stop when they block on the
	  mutex lock. Thus one receive thread hanging
	  will effectively stop all send threads, which
	  in turn will stop all remaining receive threads;
	
	It appears that something is causing the mutex
	not to be unlocked at some point, and all threads
	consequently block on the mutex lock.

I've attached the modified test code in case someone has time to 
look at it. 99% of the code is just execution tracing. You'll have 
to see the code to interpret the log output though (unfortunately).

Ross

Nir Nizry wrote:
 > Hello All,
 >
 > I have a problem with pthread_cond_timedwait().
 > I have a system with 5 threads that in their main loop wait with 
a timeout
 > (timedwait) on a condition variable to be set.
 > what I get is, that sometimes a thread enters the 
pthread_cond_timedwait()
 > function, and doesn't come out, even if the timeout time arrives. 
after this
 > happens, the other threads get stuck in the mutex lock before 
entering the
 > pthread_cond_timedwait() as if the mutex is already locked.
 >
 > I suspect that somehow either the pthread_cond_timedwait() 
function does not
 > release the mutex or does not return when the timeout occurs.
 >
 > does someone have an idea' or know of such an incident (or maybe 
a bug in
 > pthread)??
 >
 > Thanks.
 >
 > Nir.
 >
 > I added the code fraction where it get stucked (this is the ONLY 
place in
 > the code where the messageMutex is locked):
 >
 >
 > pthread_mutex_lock(messageMutex);
 >
 > waitResult = 0;
 > while( m_theGeneralQueue->isEmpty() && !shouldStopThreadGlobalLoop &&
 > (waitResult != ETIMEDOUT))
 > 	waitResult = pthread_cond_timedwait(newMessageEvent, messageMutex,
 > &timeout);
 >
 > pthread_mutex_unlock(messageMutex);
 >
 >
 > -----------------------------------------
 >
 > mailto:nir.nizry@bluesoft-inc.com
 >
 > -----------------------------------------


-- 
+-------------------------+---+
| Ross Johnson            |   | "Come down off the cross
| Management & Technology |___|  We can use the wood" - Tom Waits
| Building 11                 |
| University of Canberra      | eMail: rpj@ise.canberra.edu.au
| ACT    2601                 | WWW:
http://public.ise.canberra.edu.au/~rpj/
| AUSTRALIA                   |
+-----------------------------+
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: condvar10.c
URL: <http://sourceware.org/pipermail/pthreads-win32/attachments/20020724/4c886077/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: condvar10.h
Type: type=text/plain
Size: 767 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/pthreads-win32/attachments/20020724/4c886077/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile
URL: <http://sourceware.org/pipermail/pthreads-win32/attachments/20020724/4c886077/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: GNUmakefile
URL: <http://sourceware.org/pipermail/pthreads-win32/attachments/20020724/4c886077/attachment-0001.ksh>