known synchronized() failures?

[Bryce McKinlay]

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