• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Thread Question

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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-
 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
reply
    Bookmark Topic Watch Topic
  • New Topic