known synchronized() failures?

[Thomas Aeby]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20050502/78faa1a8/attachment.sig>