Re: known synchronized() failures?

[Thomas Aeby <aeby at graeff dot com>]

On Mon, 2005-05-02 at 14:37 +0200, Thomas Aeby wrote:
> typical stack trace of the process consuming all the CPU (and is the
> one who is trying to get a lock) looks like
> 
> /disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-20.test2/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/linuxthreads/restart.h:24
> /disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-20.test2/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/linuxthreads/mutex.c:199
> ../../../gcc-4.0.0/libjava/posix-threads.cc:192
> ../../../gcc-4.0.0/libjava/java/lang/natObject.cc:929

Oh, and as I look at posix-threads.cc: I might have to add that the
thread actually being blocked at the beginning of the synchronized() {}
block is actually in "interrupted" state (don't know if it is from the
start since the idea behind is that the thread starts a few sub threads
which will interrupt() after a while) ... hmh, I can't say what
_Jv_CondWait() is supposed to do in this case

Best regards,
Tom

----------------------------------------------------------------------------
Thomas Aeby, Kirchweg 52, 1735 Giffers, Switzerland, Tel: (+41)264180040
Internet: aeby@graeff.com                       PGP public key available
----------------------------------------------------------------------------

Attachment: signature.asc
Description: This is a digitally signed message part