Re: libgcj/117: _Jv_PthreadCheckMonitor test is not portable.

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Joerg Brunsmann wrote:

> 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:

> 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?

Solaris does have recursive mutexes, at least according to the man pages in 2.7, so I think
having HAVE_RECURSIVE_MUTEX defined is correct in your case. The problem is that the semantics
of various pthread_* calls are somewhat different between linux and solaris. pthread_cond_wait
and friends definatly should not be called without the mutex held, but I have no idea why it
isn't held in your case.

I personally think its going to be rather difficult/messy to implement completly working java
threads functionality (including things like interrupt()) for the various different pthread
implementations in the same code. Its already pretty messy with all the HAVE_RECURSIVE_MUTEX
#ifdefs. Perhaps we should eventually look at having posix-threads.cc providing a minimum set
of pthreads functionality (without assuming things like recursive mutexes), and then have more
specific implementations (linux-threads.cc, solaris-threads.cc) to take advantage of more
efficient platform features and do the "harder" stuff.

regards

  [ bryce ]