libgcj/117: _Jv_PthreadCheckMonitor test is not portable.

Thu Dec 9 03:08:00 GMT 1999

Tom Tromey wrote:
Sorry, I'm resending this because it fails to be accepted by java-prs.
> I apparently forgot about the no-recursive-mutexes case when writing
> this code. Can you try this patch? I haven't even tried compiling
> it... but if it fails, it at least gives the general idea of what to do.

Thanks, I applied the patch but unfortunately it doesn't help. If Solaris
doesn't have recursive mutexes I don't understand the lines in posix-threads.h 
and java-thread.h:
#if defined (HAVE_PTHREAD_MUTEXATTR_SETTYPE) || defined (HAVE_PTHREAD_MUTEXATTR_SETKIND_NP)
# define HAVE_RECURSIVE_MUTEX 1
#endif
In config.h HAVE_PTHREAD_MUTEXATTR_SETTYPE gets defined, and hence
HAVE_RECURSIVE_MUTEX is defined also. Is this correct? What am I missing here?
The problem is that the waiting thread doesn't get nofified, that is: the 
pthread_cond_wait doesn't return (in function If you give the waiting thread 
a timeout (via pthread_cond_timedwait) it does return with the ETIMOUT value, 
that means that the waiting thread is still alive but the sigmaling/notifieng 
doesn't work. If i consult the man pages I see:
 pthread_cond_wait() and pthread_cond_timedwait() block on a
 condition variable, which atomically release the mutex
 pointed to by mp and cause the calling thread to block on
 the condition variable pointed to by cond. The blocked
 thread may be awakened by pthread_cond_signal(),
 pthread_cond_broadcast(), or interrupted by a UNIX signal.
Given that, I don't understand this: In the last line of _Jv_PthreadCheckMonitor the 
function pthread_mutex_unlock is called; the mutex is now unlocked. If I now call
pthread_mutex_trylock in function _Jv_CondWait I get the result that the mutex is 
not locked by this thread. Now _Jv_CondWait calls pthread_cond_(timed)wait although 
is doesn't hold the mutex. Is this a valid objection or do I need a tutorial for
pthread beginners?
Thanks,
JÃƒÂ¶rg