• Post Reply Bookmark Topic Watch Topic
  • New Topic

Waiting Thread

 
JiaPei Jen
Ranch Hand
Posts: 1309
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am stuck with this concept:
At any moment, may a thread be waiting for the lock of more than
one object?
Could anyone help me?
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JiaPei,
Good question. I haven't seen one this good in quite some time, so bear with me while I ramble.
I can think of two circumstances in which a thread contends for an object's lock. (I say "contend for" rather than "wait for" because it's helpful to differentiate between threads actively trying to get a lock and those in a wait set.) One, the thread is attempting to enter a synchronized block and needs the lock of that block's monitor object. Two, the thread has just been moved out of an object's wait set and is trying to get that object's lock to continue execution inside a sync'ed block.
Your question implies that the thread is waiting in a sync'ed block nested inside another sync'ed block, with the two blocks sync'ed on different objects. After all, <code>wait</code> doesn't return until the thread regains the lock, so there's no way for the thread to simultaneously be executing two calls to <code>wait</code>. Let's assume that the thread encountered a <code>wait</code> statement inside the inner block, and so entered the wait set of that block's monitor object. At that time, it relinquished the inner monitor's lock. But, I don't think it gave up the outer monitor's lock. Your question hinges on this issue. Since the loss of the lock is a function of the <code>wait</code> method of the monitor object, and one monitor object doesn't know about another, I would say "no".
Note that this reasoning is not affected by the possibility that the thread may have performed multiple lock operations on a single monitor. When the thread enters the wait set, unlock is performed as many times as necessary to fully relinquish the lock. When the thread exits the wait set and regains the lock, the lock operation is performed as many times as necessary to bring the thread to its previous state.
Aha! Just found the answer in Lea (Concurrent Programming in Java, 2nd ed., p.184). The thread does not relinquish any other locks. Now I think I can give you a definitive answer - No, at any moment, a thread may not be contending for the lock of more than one object.
Whew. Good exercise.
jply
 
JiaPei Jen
Ranch Hand
Posts: 1309
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Jerry:
Thank you for taking so much time to answer my question. I am still a sort of confused. Allow me to lay out my thoughts:
Step 1. A thread (t) may own several locks at the same time, say, the thread t has the lock on object A, the lock on object B, and the lock on object C.
Step 2. The thread t releases the lock on object A upon executing that object's wait() method embedded in the synch'ed method/block of codes and enters the waiting state. At this point, the thread t still has the lock on object B and the lock on object C.
Step 3. Is it possible that sometime after step 2 and before the current owner of object A's lock executes the notifyAll(), the thread t gives up the lock on object B by executing the wait() method? Of course, the thread t still has the lock on object C.
Question 1: Under the above circumstance, does it mean that the thread t is waiting for the lock of more than one object?
Question 2: In case that both the current owner of object A's lock and the current owner of object B's lock ( who, of course, is a different guy) execute notifyAll(). At this stage, does the thread t contends for the lock on object A and object B simultaneously?
Thank you in advance.
JiaPei Jen
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JaiPei,
In Step 3, the thread is blocked in the <code>wait</code> method of A, so it can't execute any other code. There's no way for it to release B's lock - it would have to execute B's <code>wait</code> or leave B's sync'ed block to do so.
jply
 
JiaPei Jen
Ranch Hand
Posts: 1309
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I appreciate your explanations. Thanks a lot.
Jia Pei
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!