File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes IllegalMonitorStateException - Different in J2ME? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "IllegalMonitorStateException - Different in J2ME?" Watch "IllegalMonitorStateException - Different in J2ME?" New topic
Author

IllegalMonitorStateException - Different in J2ME?

Alan Walker
Greenhorn

Joined: Feb 15, 2004
Posts: 26
Hi
I posted this question a few weeks back in the J2ME forum and got no replies at all, so I thought I'd see if any thread gurus can help.
Does anyone know of a difference between J2ME and J2SE in the conditions that cause an IllegalMonitorStateException to be thrown?
When I forgot to synchronize a call to the notifyAll method in a midlet, it didn't throw an exception most of the time, even though it seems like it should have, because the current thread did not own the monitor of the object whose notifyAll method was being called.
Consider the following class (I have created this to demonstrate my question - my own original code is too full of irrelevant complications to be a good illustration of the issue).


If I create an instance of this class in a J2SE applet, the constructor throws an IllegalMonitorStateException. The exception can be eliminated by putting the notifyAll call inside a synchronized(this) {} block. All this seems to be just the way it should be.
But now, if I put the above code (without the notifyAll being synchronized) into a midlet and create an instance of the ThreadTest class, there is no exception. I have observed this on various emulators and on a Nokia series 40 phone (6610).
However, if I comment out the t.start() line, an IllegalMonitorStateException is thrown. It seems as if the existence of a waiting thread at the time of the call to notifyAll prevents the exception.
Has anybody come across this before? Am I misunderstanding something about this exception? I'd be grateful for any enlightenment.


Chihuahua - Ajax-powered online word puzzle, <a href="http://chi.lexigame.com" target="_blank" rel="nofollow">http://chi.lexigame.com</a> <br />Letterbox Word Game Online, <a href="http://letterbox.lexigame.com" target="_blank" rel="nofollow">http://letterbox.lexigame.com</a> <br />Lexi Word Game for Java-enabled phones, <a href="http://www.lexigame.com" target="_blank" rel="nofollow">http://www.lexigame.com</a>
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

looks like an error to me.
Of course you should not be using synchronized methods anyway, nor should you be synchronizing the run method for sure. But the point is taken, this seems like a bug. Perhaps they are emulating multiple threads in a poor fashion and not releasing locks when they shift between them.
Alan Walker
Greenhorn

Joined: Feb 15, 2004
Posts: 26
Originally posted by CL Gilbert:
...Of course you should not be using synchronized methods anyway, nor should you be synchronizing the run method for sure...

Is this always true? I thought a synchronized method was one of the accepted mechanisms (along with a synchronized code block) for preventing threads from corrupting shared data.
And if a thread needs exclusive access to an object for the whole of the thread's life, wouldn't synchronizing the run method be one way of achieving that? For example, a thread could be spawned to read a file and initialize a data structure - no other thread should try to access the data structure while the initialization thread is running. In that case, why not synchronize the run method of the thread's runnable class, and also synchronize (on the same object) the access methods to the data structure?
Alan
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

it is accepted, but its also flawed. it violates encapsulation. You should always use your own lock objects to synch on. Hide your lock object like any other member of your class. If you use 'this' as a lock object, then you are exposing it to the public.
Java should simply rid itself of synchronized methods. But I dont like to force things on people. To each his own.
NOTE: You can also apply this same principle to wait objects. Wait on specific objects created for the purpose of waiting. And hide them as much as possible.
[ March 23, 2004: Message edited by: CL Gilbert ]
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

I still say this is a bug. But if you want to really "bake your noodle," then have a look at Thread.join. When you understand how Thread.join() works, and that it violates encapsulation, you will see new complications to your test case.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

check what happens if you
t.setDaemon(true);
Alan Walker
Greenhorn

Joined: Feb 15, 2004
Posts: 26
Thanks for your comments. I'll have to think over your points about encapsulation.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: IllegalMonitorStateException - Different in J2ME?