This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
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.
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
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???
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...
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).
Joined: Jun 15, 2009
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???
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.