known synchronized() failures?

Wed Apr 27 21:46:00 GMT 2005

Martin Egholm Nielsen wrote:
>> 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.
>> Interesting thread, as I use 3.4.3 and would want to make it "better".
> So, actually I should grab the natObject.cc from CVS (or 1.31 at 
> least), and then sync'ing should be at least as good as before.

That should work, I think. I can't recall any other changes to natObject 
that would make it incompatible, but its possible you may have to hack 
it slightly.
> I haven't seen any IllegalMonitorStateException yet, though, but I 
> surely don't wanna have them comming when my application is out and 
> running in the field.

Yes, although note that we only ever saw 16662 on MP systems - it 
shouldn't be a problem on a uniprocessor machine.
> However, I stumbled across one note Hans made in this patch:
>> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natObject.cc.diff?cvsroot=gcc&r1=1.30&r2=1.31 
>>> + // FIXME: Does this make sense on a uniprocessor, where
> + // it actually yields? It's probably cheaper to convert.
>> I worry about the question about "making sense on a uniprocessor" - 
> since this is where I'm targeted...

Hans is referring to whether there is any performance advantage to 
spinning on lock aquisition on a uniprocessor machine - spinning only 
really makes sense when the lock may be held by a thread running on 
another CPU. It should not be a correctness issue, however.
Regards
Bryce