This week's book giveaway is in the Design forum.
We're giving away four copies of Design for the Mind and have Victor S. Yocco on-line!
See this thread for details.
Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Thread Question

 
Dave Wolf
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In K&B's Java 2 SCP&D certification book, chapter 9, self test question 13...
13. Assume the following method is properly synchronized and called from a thread A on an object B:
wait(2000);
After calling this method, when will the thread A become a candidate to get another turn at
the CPU?
A. After thread A is notified, or after two seconds.
B. After the lock on B is released, or after two seconds.
C. Two seconds after thread A is notified.
D. Two seconds after lock B is released.
The correct answer as given in the key is 'A'.
My question is, would it be more accurate to say:
'(After thread A is notified AND the lock on B is released) OR after two seconds.'?
Once thread A is notified isn't it possible for thread A to be blocked on B's lock for a short period of time until the synchronized code in B is finished executing. What am I missing here?
Thanks,
-Dave-
 
David Hadiprijanto
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Dave,
I don't think answer A needs to be ammended by "lock on object B is released".
Here is why I think so :
[1] A calls wait(2000) on object B. A is therefore now in B's waiting list (blocked).
[2] After 2 seconds or A is notified, A is moved back to Runnable state (will be a candidate to get another turn at the CPU).
[3] A is picked by the Thread scheduler to run. Since it is still running in the synchronized context of object B, it will need object B's lock. So, if the object B's lock is being used by other thread (not released yet), Thread A will be blocked again.
In another words, for thread A to move back to Runnable state from Waiting state as a result of calls to wait(2000) on object B, it only needs 2 seconds or being notified.
Now, your comments :

Once thread A is notified isn't it possible for thread A to be blocked on B's lock for a short period of time until the synchronized code in B is finished executing. What am I missing here?

Yes, this will be at point [3] above, but beforehand, at point [2] thread A is already back in Runnable state - it just got 'unlucky' to be thrown to Blocking state again .
Does it make sense?
 
Dave Wolf
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by David Hadiprijanto:

Does it make sense?

Yes, it does now. For whatever reason, I had it in my head that a thread that was 'waiting' could not move to the runnable state, even after being notified, if the synchronized code that was calling notify() was not done running yet.
Thank you for clearing that up.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic