ujjawal rohra wrote:
In line 1 the wait() method is called on an instance of t or Trd and
for whose instance is it waiting t or Trd ???
Answer is Trd, reason is - when you call wait() it releases the monitor for of the "this" instance and goes to waiting state. in this case the "this" variable refers to an instance of Trd supplied while creating a new thread.
The current threat 't' is waiting for another thread to call notify() on object 'trd'.
Jim ... ...
BEE MBA PMP SCJP-6
Joined: Mar 20, 2010
Ok Deepak this question is from Examlab..
In the explanation(which is really nice and detailed) it is given that wait is waiting on instance of trd
but i couldnt understand that when t is calling start then why is wait() waiting in trd???
But please clear my doubt as i am not too well on threads.
Joined: Jan 09, 2008
Inter-thread communication uses a monitor object. In one thread, you secure the
monitor's lock (every object has one) before calling its wait() method. Before calling
notify() in the other thread, the same lock must be secured there. This is why wait and
notify must always be in a synchronized code block - synchronized on the lock object.
Both threads must have access to the same monitor object. So to keep things straight,
it's often best to explicitly name the monitor object.
The code you posted notifies the thread object 't'. But in class Trd, wait is called on the
'this' object, which is the anonymous instance of Trd that was created for the Thread
constructor. Two different objects. Valid syntax but not what you want. Try this. A new object called 'lock' that is visible to both threads is added.
Then I synchronized on it before calling wait() or notify().
I encountered the same problem while resolving and reviewing the final exam (ExamLab).
Thank you for your replies, so I don't need to create a new thread concerning this subject.
Here my code which ensures that both threads access the same object, the Trd object as target (line 23 and 25), not Thread as worker.
A crucial point to remember is that notifAll() should be applied to the Trd object, as well - otherwise, we get an IllegalMonitorStateException.
Nevertheless, I'm wondering why we don't get an IllegalMonitorStateException when we call notifyAll on the worker (Thread) - maybe, it has to do with the fact that target and worker are connected with each other?
One point I can't understand is why it works, as well ... when we apply synchronized() and notifyAll() on two different target instances (Trd, see line 20).
Assertion :- We cannot say for sure that "Printed" would ultimately be printed. Is that true ???
Although it is more likely that it would get printed. I mean in a nutshell, Can we guarantee that if only one thread is present in the runnable state , it would definitely be scheduled. It should be but it is always said that Scheduling is not guaranteed.
Proposed solution of Ulrich Vormbrock is correct and the code will work as expected. Vormbrock discussed about some issues after his code block which are interesting.
IllegalMonitorStateException will be thrown at runtime for notifyAll() method if it is called on an object on which the current thread is not synchronized. In your case, notifyAll() is called on that object on which the current thread is synchronized, that is, trd object of the Trd class.
In your second issue, if you replace your line 20, as following: Thread t = new Thread(new Trd()); your code will compile without error and run without any runtime error but you will not get the expected result since in this case, your wait() method is called on and the executing thread of the wait() method is synchronized on an instance of the Trd class which is different Trd class instance on which the notifyAll() method is called on and the main thread is synchronized for the fine grain block. In this case the waiting thread will not get the notification since it is waiting in the different Trd instance waiting list.