This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Threads and Synchronization and the fly likes Thread Illeagal Monitor State Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Thread Illeagal Monitor State" Watch "Thread Illeagal Monitor State" New topic
Author

Thread Illeagal Monitor State

rajshkhr pandey
Ranch Hand

Joined: Oct 14, 2009
Posts: 35
Hello to all,

I am try to run a RMI application in which the server call backs to the client on some event occur on server side.
my client side code is


the MyNewThread.java contains


but when I run this code it catch an exception


and when server call me back i.e. sends me username again same exception caught.

So what can I do???
My aim is to make thread wait utill server calls back to me
As soon as server calls back the thread wake up and completes the work and again goes into wait mode or sleep mode
Adam Michalik
Ranch Hand

Joined: Feb 18, 2008
Posts: 128
The wait() and notify() methods must be called from inside a synchronized block (synchronized on the object you call wait() and notify() on) ie. the current thread must own the object's monitor = object's lock.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

The locks to the objects you call wait() and notify() on have to be owned by the thread which calls those methods - which means you have to put those calls in a synchronized block:





There are other alternatives which may make better sense to use in this scenario (and be easier to implement). Things that come to mind would be a BlockingQueue implementation (a SynchronousQueue maybe), a Semaphore, an Exchanger, CyclicBarrier ... It depends on the semantics of communication between the two Threads (1-1 signaler to receiver, do they both have to hit the point at the same time, can the signaler preemptively tell the receiver it can go, is there actual data to exchange, etc...)


Steve
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18757
    
  40

Adam Michalik wrote:The wait() and notify() methods must be called from inside a synchronized block (synchronized on the object you call wait() and notify() on) ie. the current thread must own the object's monitor = object's lock.


And of course, just adding the synchronization may only solve the symptom. Keep in mind that the requirement of owning the lock wasn't just added to be annoying. There are race conditions that can't be solved, if the wait() method didn't release the lock for you. So, it would be a good idea to understand how to use it too.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Ireneusz Kordal
Ranch Hand

Joined: Jun 21, 2008
Posts: 423


In case when idleCount ==0 && isFull() == true you dont start a new thread, but simply exit returning true.
You don't show here how isFull() works and where idleCount is changed.
I guess that this condition should never happen ..... but who knows ;)
Change this fragment into:
and run your programm with assertion enabled.

BTW, in this code fragment:

'if' and 'break' is unnecessary (you have the same condition in the while loop).
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Thread Illeagal Monitor State