aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Thread Question from Examlab 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 "Thread Question from Examlab" Watch "Thread Question from Examlab" New topic
Author

Thread Question from Examlab

Anu Bhagat
Ranch Hand

Joined: Jun 20, 2008
Posts: 64
Hi

I don't understand why Thread t is not coming out of wait.

Looks like the notifyAll has been invoked corrcetly.

here is the code



It prints "Ready to print, Now prining," and then hangs. I thought I understand this but not anymore.

Please clarify why thread t is waiting forever...What has to be done to bring t out of wait.

Thanks.

Anu


SCJP5.0, SCJA
Morteza Manavi-Parast
Ranch Hand

Joined: Dec 25, 2008
Posts: 66
That's becasue thread t is wait for the object Trd (wait means this.wait() and this is refer to the runnable trd object), and the main thread notifyall() the thread t object! No! that's not right! Main thread should have notifyall the trd object instead.


SCJP 6
Swapnil Shroff
Ranch Hand

Joined: Mar 07, 2006
Posts: 58
Wait and notify concept is always linked to threads but they are methods in Object, not Thread. If you try to use them on a
Thread object you may not get the results you expect.
I will try to explain here-
Producer and Consumer is a classic example however to make it interesting consider following scenario below

We have a Bar Object and 3 working thread (2 bar tender and 1 helper)

Object Bar has 2 methods getGlass and putGlass and List of glasses. When a bar tender wants a glass it will call getGlass method of bar object and helper calls putGlass to place a glass on shelf.

Each time getGlass is called a glass is subtracted from list similarly each time put is called glass is added to List.

Now when list becomes empty and there are no glasses in the bar then any bar tender that calls getGlass would be asked to wait. And when helper thread calls putGlass then all bar tender thread gets notified as they are waiting. You can assume that the notifying mechanism is internal to restaurant(jvm )

For your example, the right way would be-


hope it helps


SCJP 5, SCDJWS<br /> <br />It's amazing how premature optimisation is both seductive and destructive; even when you know
Anu Bhagat
Ranch Hand

Joined: Jun 20, 2008
Posts: 64
Thanks for explaining Swapnil.

Anu
daniele ippoliti
Greenhorn

Joined: Jun 15, 2009
Posts: 6
hi i don't understand why the output is "Ready to print, Now prining," Is not possible that the output was " Now prining,Ready to print," ??? Why?

thanks

Daniele
Meghna Bhardwaj
Ranch Hand

Joined: Jun 08, 2007
Posts: 109
HI All,

I understand this question and the solution to it. As the wait and notify are not both working on the same objects Lock. However , I have the same question as daniele... is it not possible that inside run() the JVM decides to switch threads and starts executing main thread before "Ready to Print" gets executed....therefore producing the output...
"Now Printing," first???
Alexander Danilou
Greenhorn

Joined: May 08, 2009
Posts: 28
My understanding that output "Ready to print, Now prining," is not guaranteed. Most likely in this case it will be in 99.9% probability, because main thread sleeps for 1 second and it usually gives enough time for t to grab the lock...
Mo Jay
Ranch Hand

Joined: Feb 16, 2009
Posts: 83
Given the code above, if you want the output as you like this: Now printing,Ready to print, then the output : Printed will never be executed and the thread will hand there on wait() method FOREVER. If you reduce the sleep time for the main thread to lets say 100 then Printed will never be reached. Do you know why? it is because notifyAll() is all already called upon after main thread printed Now Printing, therefore doMore() will wait() forever on some notification that will never show up because it is already passed. That's why there is a rule that says: you should always know what you are waiting for, and if what you are waiting is still to come OR it is already passed (executed).

Cheers!!
daniele ippoliti
Greenhorn

Joined: Jun 15, 2009
Posts: 6
sorry but the question says: which kind of output produce the code...and also if the probability are 99,9% that this code produce Ready to print,Now printing for sleep time values, there is the 0,01% of probability that output is Now printing,Ready to print...so the answer "output is Ready to print,Now printing" is wrong!!! is it right my observation???
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18981
    
  40

daniele ippoliti wrote:sorry but the question says: which kind of output produce the code...and also if the probability are 99,9% that this code produce Ready to print,Now printing for sleep time values, there is the 0,01% of probability that output is Now printing,Ready to print...so the answer "output is Ready to print,Now printing" is wrong!!! is it right my observation???


It's an interesting point. It is *theoretically* possible for the code to produce the output (not 0.01%), but in reality, the probability is likely zero. For the output to happen, you would need a JVM that can't schedule a running thread within a half second. You really need something extreme for that to happen.

But yes, you are right.... it is theoretically possible, as there is nothing in the specification that will prevent it from happening.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Thread Question from Examlab