Re: New java.lang.Thread tests

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Tue, 2002-10-08 at 22:43, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:
> 
> Mark> Another was to not hold a synchronized lock on the Thread object that
> Mark> you are trying to join() with. That solved the Kissme and gij lockup.
> Mark> But I think that you should be able to join() a Thread that you (or
> Mark> someone else!) has a lock on. What do you think?
> 
> I agree.
> 
> I don't understand why you needed such a lock for gcj.
> In Thread.join(long,int) (in natThread.cc), we acquire a mutex 
> before waiting on the condition variable.  Both the mutex and the
> condition variable are not visible to Java code.

I didn't need it for the join() but I needed it since I wanted to
notify() the Thread object. The join() just happened to be included in
the synchronized block by accident. See the diff between the original
isAlive test and the new one.

cvs diff -r 1.1 gnu/testlet/java/lang/Thread/isAlive.java

With the original code that test will hang with gij after:
PASS: gnu.testlet.java.lang.Thread.isAlive: Running threads are alive (number 1)

Moving the join() outside the synchronized block makes the test work
(and it is a bit cleaner code).
I have not yet analyzed why the original program hangs with gij.
But if people agree that the original code also is legal then I can add
an extra test for that case.
Kaffe has no problem with the original code.

Cheers,

Mark