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

Thread Question

Mike Cutter
Ranch Hand

Joined: Jun 09, 2002
Posts: 49
I am having problems with figuring out this thread question from a mock exam.
Thread T1 holds the lock on object Obj. Thread T2 is blocked inside a wait call on object Obj. What allows Thread T2 to become runnable?
A. Thread T2's wait() times out.
B. Thread T1 calls Thread.sleep(100).
C. Thread T1 is interrupted.
D. Thread T2 is interrupted.
E. Thread T1 release the lock on Obj and calls the notify() method on object Obj.
F. Thread T1 release the lock on Obj and calls the notify() method on thread T2.
A detailed explanation to help me understand would be appreciated to help study for the certification exam.
Alfred Kemety
Ranch Hand

Joined: Aug 14, 2002
Posts: 279
Well, T2 can only access obj if the lock T1 has on the object obj is unlocked. The fact that the thread is in the ready-to-run state or in the running state doesn't affect this part "gaining back the ownership of the monitor of the object obj" as long as T1 owns it. In other words, if T2 is notified and moves from ready-to-run to the running state while T1 is still having the wonership of the monitor on obj, this will not give T2 access to obj.
So first T1 has to "relenquish" the monitor on obj. Then for T2 to gain the ownership of the monitor of obj then "I think" it has to be back to the running state first, and since wait() has been called in T2, then T1 should notify() it. So I guess the answer would be the last choice, if I'm not mistaken.


Alfred Raouf - Egypt - SCJP 1.4<br />Kemety.equals(Egyptian) // returns true
Vin Kris
Ranch Hand

Joined: Jun 17, 2002
Posts: 154
This is how I interpret the situation -
Thread T1 -
synchronized(obj) {
// doing something
}
Thread T2 -
synchronized(obj) {
while( <some condition> || <some other condition> ) {
try { obj.wait(1000); } catch(InterruptedException e) {}
// try { obj.wait(); } catch(InterruptedException e) {}
}
}
The question is asking "what makes the thread T2 runnable". It is not required for the thread to run - just be runnable or ready-to-run.
Then the choices A,D & E seem appropriate.
The choice E may actually cause the thread T2 to be running - if there are no other threads waiting on the same object.
This is what Java Doc says on the condition of the thread after wait() -

The thread T is then removed from the wait set for this object and re-enabled for thread scheduling. It then competes in the usual manner with other threads for the right to synchronize on the object; ...

Plz feel free to correct me.
Alfred Kemety
Ranch Hand

Joined: Aug 14, 2002
Posts: 279
I guess Vin makes more sense than my first post. I went back and read about wait(), notify() and notifyall() in the java API documentation, and it explains it very good.

This method causes the current thread (call it T) to place itself in the wait set for this object and then to relinquish any and all synchronization claims on this object. Thread T becomes disabled for thread scheduling purposes and lies dormant until one of four things happens:
Some other thread invokes the notify method for this object and thread T happens to be arbitrarily chosen as the thread to be awakened.
Some other thread invokes the notifyAll method for this object.
Some other thread interrupts thread T.
The specified amount of real time has elapsed, more or less. If timeout is zero, however, then real time is not taken into consideration and the thread simply waits until notified.
The thread T is then removed from the wait set for this object and re-enabled for thread scheduling. It then competes in the usual manner with other threads for the right to synchronize on the object; once it has gained control of the object, all its synchronization claims on the object are restored to the status quo ante - that is, to the situation as of the time that the wait method was invoked. Thread T then returns from the invocation of the wait method. Thus, on return from the wait method, the synchronization state of the object and of thread T is exactly as it was when the wait method was invoked.
If the current thread is interrupted by another thread while it is waiting, then an InterruptedException is thrown. This exception is not thrown until the lock status of this object has been restored as described above.
Note that the wait method, as it places the current thread into the wait set for this object, unlocks only this object; any other objects on which the current thread may be synchronized remain locked while the thread waits.
This method should only be called by a thread that is the owner of this object's monitor. See the notify method for a description of the ways in which a thread can become the owner of a monitor.

So A, D and E makes it in the ready-to-run state "runnable", but take care of what will happen if the thread T2 is interrupted while in the wait state...
The "runnable" word tricked me in a way, I thought it means to be in the running state, I read in another post that Sun is tightening their language in the new exam. So I hope I won't be tricked a lot with these words.
 
wood burning stoves
 
subject: Thread Question