known synchronized() failures?

[Bryce McKinlay]

Thomas Aeby wrote:

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

OK, I think you are on to something here. _Jv_CondWait was designed to 
implement the Java interrupt semantics for things like Object.wait() and 
Thread.join(). However, MonitorEnter/MonitorExit are not interruptable 
and should ignore the interrupt flag completely. _Jv_MonitorEnter uses 
condition variables to implement lightweight->heavyweight lock 
inflation, but because it uses _Jv_CondWait, it can be interrupted when 
it shouldn't be. Of course, _Jv_MonitorEnter does not check for 
interruption so we just get stuck in a loop.

Here's a lame (untested) patch that should work around the problem. Can 
you try this out and see if it works for you? A better solution might be 
to implement a "light" version of _Jv_CondWait that is not interruptable.

Bryce



-------------- next part --------------
A non-text attachment was scrubbed...
Name: libjava-hashsync.patch
Type: text/x-patch
Size: 1368 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20050504/d655172f/attachment.bin>