IllegalMonitorStateException

I am getting an IllegalMonitorStateException in this code when I run it on a multiprocessor. Can anyone tell me why?

Can you check or provide the stack trace? I don't think there's anything in the code you quoted that can throw an IllegalMonitorStateException.
- Peter
PS. What's wrong with "return (gvtFlag > 0);"?

line 214 is:

I can't use the simplified verion in this case because of the relaxed memory model. The synchronized block flushes reads and writes to the variable.
...Mike B.

Hmmm... this really doesn't make sense to me. I'd go so far as to suggest that perhaps your class files aren't freshly compiled - try deleting them (at least, delete LocalOptProcessor.class) and recompile. Run again and see if you get the same message - I'm hoping it will be a different location. If that doesn't work, try posting more of the code from LocalOptProcessor.java, so we can understand the context better. Good luck...

That exception is usually tied with a call to wait() somewhere. Are you calling wait() anywhere else in your code?

I am definitely calling wait() in the Processor class, which is the LocalOptProcessor superclass. I am not calling gvtState.wait() anywhere. But if that is the origin of the error, why is the stack trace pointing to the method I have listed here? And also, why is the stack trace incomplete?
Can anyone suggest any other sources that may be able to help me with this problem? Thanks.
...Mike B.

Other methods that can throw this exception are notify() and notifyAll(). It still doesn't make sense though that the error comes from "parent.checkGVTFlag()", unless the the JVM was unable to provide a complete stack trace. Did you delete class files and recompile as I suggested? Try compiling with the -g option as well - that may help provide more info in the stack traces.
[ February 18, 2002: Message edited by: Jim Yingst ]

Regarding the weirdness of the stack trace, I was wondering if compiler optimisations might be the culprit here. Although I understand Java compilers don't tend to be very aggressive, a compiler may inline and even reorder code. That might well affect the trace.
Seconding Jim's suggestion of compiling with -g; in addition, make sure optimization is turned off. Use a different compiler if need be.
- Peter

I have refactored most of the monitors into helper classes that use fully synchronized methods. I seem to be getting far fewer of these kinds of errors now. I can only theorize that there is some problem with synchronizing a block of code on an object instance on the particular system that I am using. (SGI Origin 2000) If anyone knows anything more, I would love to hear it. Thanks.
...Mike

One hard-to-spot pitfall is synchronizing on a reference to a non-mutable object, and then later in trying to "change the state of the object" you really change the object, so subsequent monitor-related calls on the new reference produce an error. Here's a thread that discusses this issue:
http://www.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=27&t=000553

Thanks for the lead Rob. I am not sure if that is occuring in my code or not. I will definitely look deeper into it.
I have narrowed down at least one instance of the IllegalMonitorStateException, however. It seems to be happening when thread A calls interrupt on thread B, while thread B holds a lock on an Object instance inside a synchronized block. Again, it is not happening in the classes that utilize fully synchronized methods. I am not sure how interupt may interfere with the locking mechanism.
...Mike B.