wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Wait() and notify():What is the output? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Wait() and notify():What is the output?" Watch "Wait() and notify():What is the output?" New topic
Author

Wait() and notify():What is the output?

Siddharth Raja
Greenhorn

Joined: Nov 11, 2013
Posts: 18


my guess is that it will be something like:
Done: Thread-0
Done: Thread-1
........

But the real question here is.....does that notify() method serve any purpose in this example since run is synchronized? so done var will always be set to true.

another doubt: consider this.....
public void run(){ // synchronized keyword removed
for(int i=0;i<15;i++){}
notify();
done=true;

}
now is there a chance for the thread to keep waiting indefinitely when the wait() in checkDone() is called?

Siddharth Raja
Greenhorn

Joined: Nov 11, 2013
Posts: 18
sorry correction to the code:

Siddharth Raja
Greenhorn

Joined: Nov 11, 2013
Posts: 18
consider the updated code in the second post please....small changes in main method
i've completely made up this example...hence the error
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18760
    
  40

Siddharth Raja wrote:
But the real question here is.....does that notify() method serve any purpose in this example since run is synchronized? so done var will always be set to true.



What would happen if the main thread gets to the checkDone() method *before* the new thread gets to the run() method?

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Siddharth Raja
Greenhorn

Joined: Nov 11, 2013
Posts: 18
Oh yes, hadn't thought of that!

But then lets say,


does the join ensure that done will always be true for a1.checkDone()?
Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1013
    
  15
Does that code compile? Do you have access to a Java compiler?
There is no such method as getCurrentThread() in the Thread class. And that for loop requires you to correct the compilation error first.
Siddharth Raja
Greenhorn

Joined: Nov 11, 2013
Posts: 18
I'm sorry it should be Thread.currentThread().getName()

here's the code that compiles...an improved version of the previous one


now here is there a danger of the fromC.checkDone() object going into wait() indifinately as
1. synchronized for run() is commented out?
2. notify() is called before done=true in run()

Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1013
    
  15
One of the pre-requisites for a thread to invoke wait/notify on an object is that the thread holds the monitor of the object. Given that, do you see what needs to be fixed here?

Siddharth Raja wrote:


What you are doing in that try- catch to get away with the method without meeting the pre-requisites of wait/notify is not recommended.

Quick question - how are the two main methods different? How is your new main method different from what you had in example 2 viz



I've added the braces to your for loop. I guess that's what you missed in your example 1-3.
Chan.
Siddharth Raja
Greenhorn

Joined: Nov 11, 2013
Posts: 18
so you're saying that to invoke notify() in run, synchronized keyword is essential so thast obj lock may be acquired?

the new main doesnt do anythig diff fundamentally.....just that a separate calls calls checkDone() although they share the instance of a1
so, what about the two questions i asked previously?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18760
    
  40

Siddharth Raja wrote:
now here is there a danger of the fromC.checkDone() object going into wait() indifinately as
1. synchronized for run() is commented out?
2. notify() is called before done=true in run()


Not sure of the point here. You already know that without the notify(), it is possible to wait() indefinitely -- meaning it is broken. Now... you also removed the synchronization, which adds a race condition in changing the flag -- meaning you broke it some more.

What are you trying to test or confirm?

Henry

Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1013
    
  15
Siddharth Raja wrote:so you're saying that to invoke notify() in run, synchronized keyword is essential so thast obj lock may be acquired?


No. All I'm saying is that to invoke notify()/wait() on an object, a thread needs to acquire the monitor of that object. Synchronized methods is one of the ways through which a thread can acquire the monitor and hence yes that is one of the ways.

Do you know why a thread invokes wait/notify and what happens when it does so? Now since you've gotten many answers in this thread, how about you find out and tell us why a thread needs to have the monitor before it can issue a wait/notify? I think that'll be a good thing to find out.

Siddharth Raja wrote:the new main doesnt do anythig diff fundamentally.....just that a separate calls calls checkDone() although they share the instance of a1
so, what about the two questions i asked previously?


I see that you have answered my questions with another question. Well, okay...

Each of those objects ( b and c ) is encapsulating the same A object (a1 ) and you are invoking checkDone() on that same object from the same thread, i.e main ( ignoring your changes to the other method - we are only talking about your main method here ). So then how would they be different. Henry has already answered your two questions. And his response has a question for you.

Chan.




Siddharth Raja
Greenhorn

Joined: Nov 11, 2013
Posts: 18
Well, the thread invoking wait/notify would obviously need a lock because these methods enforce the mutual exclusion concept. if lock was not needed, then obviously any thread could invoke the wait/notify for any object and that would be an absurd situation.

Henry's question was more of an answer to the query i raised whether the checkDone() method will always return true... Henry pointed out that a1.checkDone() could simply be executed first and hence the wait() was necessary...i even responded to that

but there was also another doubt i'd asked and i'm still seeking an answer for this:
another doubt: consider this.....
public void run(){ // synchronized keyword removed
for(int i=0;i<15;i++){}
notify();
done=true;

}
now is there a chance for the thread to keep waiting indefinitely when the wait() in checkDone() is called?
Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1013
    
  15
Ok I will address only this part. And I'm hoping Henry will consider to correct me if I'm wrong.

Well, the thread invoking wait/notify would obviously need a lock because these methods enforce the mutual exclusion concept. if lock was not needed, then obviously any thread could invoke the wait/notify for any object and that would be an absurd situation.


When a thread invokes wait() on an object, it gives up the monitor it has and waits for somebody ( another thread that will subsequently acquire the monitor ) to signal to it that some event has taken place. So when a thread gives up its monitor, one of the other threads can acquire it and choose to signal the waiting thread that something has happened. Generally a thread notifies around the same time when it's almost done with any task that required it to hold the monitor - but this is not a requirement ( a notify does not cause a thread to give up the monitor), it is more of the usual way these things are coded ( you know why - cause it is sensible of other threads to try to acquire the monitor again ). So the waiting threads can now try to acquire the monitor again and check if the event that they were waiting for has really happened and can continue with the processing if they can get the monitor again. A waiting thread needs to reacquire the monitor to return from the wait method.


Edit : And it would be disastrous if the wait could return without the thread reacquiring the monitor because this thread could miss on the notification while checking if the event for which it was waiting has happened ( in case the event didn't happen with its previous wait ) and before acquiring the monitor and issuing another wait. Since a wait cannot return before the thread reacquires the monitor, this disastrous case is not a possibility.

Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18760
    
  40

Siddharth Raja wrote:
but there was also another doubt i'd asked and i'm still seeking an answer for this:
another doubt: consider this.....
public void run(){ // synchronized keyword removed
for(int i=0;i<15;i++){}
notify();
done=true;

}
now is there a chance for the thread to keep waiting indefinitely when the wait() in checkDone() is called?


Well, considering that the notify() call will fail, with an illegal state exception, because you can't call notify without the lock -- there isn't anything to wake up the wait() thread call. Also, the done flag will never be set to true because of the exception. Does that help answer your question?

Henry
 
 
subject: Wait() and notify():What is the output?