known synchronized() failures?

Wed Apr 27 16:38:00 GMT 2005

Thomas,
There is a known bug in the synchronization implementation prior to GCC 
4.0 - see PR 16662. Unfortunately that fix doesn't seem to have made it 
into the 3.4 branch.
However, the symptoms of that problem are an 
IllegalMonitorStateException - I'm not aware of any bugs that would 
cause the symptoms you describe. The hash synchronization code does spin 
when aquiring locks, but should never spin forever. With the fix to 
16662, Hans introduced some debugging code that should make it easier to 
track down synchronization problems (you need to define LOCK_DEBUG in 
natObject.cc).
I suggest:
- Try again with GCC 4.0, or a 3.4 tree with the 16662 fix applied, and 
see if the bug still occurs.
- If you still see the bug, build a libgcj with LOCK_DEBUG enabled, 
attach to the locked process in gdb, inspect the thread stacks and post 
what you see here.
Regards
Bryce
Thomas Aeby wrote:
>The last few days I spent on debuggin a really unpleasant problem. One
>of my programs making extensive use of locks ("synchronized") is
>reproducibly hanging after a while of operation. After quite some
>debugging I'm sure that it is hanging at the start of a synchronized()
>block:
>> Vector jobqueue = ...
> ...
> while( doagain )
>	mythread.setName( "Loop" );
>	synchronized( jobqueue ) {
>	 mythread.setName( "Loop" );
>	 ....
> }
>>The intention is to process a queue within a loop, and each loop give
>up the lock so that other threads get a chance to get the jobqueue
>lock, too. Obviously, this thread is hanging sometimes at the beginning
>of the synchronized() block, thus when printing out the names of the
>existing Threads the thread prints as "Loop", the pstack utility tells
>me the same. Just some deadlock in my code, you are telling me? Read
>on :-)
>>At the time the synchronized() hangs another thread (the one holding
>the lock at that moment) hangs at the end of a similiar synchronized()
>block.
>>The thread hanging at the start of the block consumes 100% CPU,
>therefore must be in some busy-waiting loop????
>>Both this observations tell me that this is not a bug in my Java
>code since one thread is about to give up a lock while the other is
>trying to claim the same lock - so no deadlock.
>>Unfortunately, I haven't been able to write a testcase showing the
>same misbehaviour, it's probably just some race condition that is
>not easy to reproduce.
>>I've tested GCJ 3.3.5 and 3.4.4 (Debian).
>>Has anyone made the same observations, is the problem known and does
>anyone know a workaround or a solution for this? synchronized() not
>working reliable looks like a serious problem to me since it's commonly
>used throughout any Java code including libgcj ...
>>Thank you very much for any hint.
>Best regards,
>Tom
>>