• Post Reply Bookmark Topic Watch Topic
  • New Topic

BLOCKED state - who's bocking the thread ?  RSS feed

 
Puscas Marin
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

my understanding of thread states is same as Alain Dickson's in http://www.coderanch.com/t/425685/threads/java/Blocked-Waiting-Thread
What I do not udnerstand is how is it possible for a thread to show itself in BLOCKED state in a thread dump but somehow the monitor on which our blocked thread has blocked on has not been acquired by any other (I would guess RUNNABLE) thread.

Thanks for the insights!
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Puscas Marin wrote:...What I do not udnerstand is how is it possible for a thread to show itself in BLOCKED state in a thread dump but somehow the monitor on which our blocked thread has blocked on has not been acquired by any other... thread

What makes you think it an be?

...been acquired by any other (I would guess RUNNABLE) thread.

Why do you guess the other thread would be in the runnable state? I would think the only thing you can say about the thread which holds the lock would be that it could not be in the new or terminated state.
 
Puscas Marin
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steve Luke wrote:
Puscas Marin wrote:...What I do not udnerstand is how is it possible for a thread to show itself in BLOCKED state in a thread dump but somehow the monitor on which our blocked thread has blocked on has not been acquired by any other... thread

What makes you think it an be?


Well, http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Thread.State.html#BLOCKED tells us that " A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method or reenter a synchronized block/method after calling Object.wait. ". I just can't think of another reason for such a scenario aside from a competing thread getting hold on that same lock our BLOCKED thread has been previously waiting on.

...been acquired by any other (I would guess RUNNABLE) thread.

Why do you guess the other thread would be in the runnable state? I would think the only thing you can say about the thread which holds the lock would be that it could not be in the new or terminated state.

And that thread shoud be in a RUNNABLE state - as soon as it switches to (TIMED) WAITING it releases all locks it holds. That means our BLOCKED thread will start running. Or stay blocked because another BLOCKED thread would acuqire that lock first.

What am i missing ?
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Puscas Marin wrote:Well, http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Thread.State.html#BLOCKED tells us that " A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method or reenter a synchronized block/method after calling Object.wait. ". I just can't think of another reason for such a scenario aside from a competing thread getting hold on that same lock our BLOCKED thread has been previously waiting on.

Right, but your question was, how could a thread be blocked when no other thread holds the lock. So my question is: why did you ask this question? What makes you think it is possible, when the rules say it isn't?

Why do you guess the other thread would be in the runnable state? I would think the only thing you can say about the thread which holds the lock would be that it could not be in the new or terminated state.

And that thread shoud be in a RUNNABLE state - as soon as it switches to (TIMED) WAITING it releases all locks it holds. That means our BLOCKED thread will start running. Or stay blocked because another BLOCKED thread would acuqire that lock first.
It could be blocked on a different lock. A timed wait does not necessarily release all (or any) of the locks it holds (example, Thread.sleep() puts the thread into a timed wait and does not release any locks). I would also question weather waiting releases all locks it holds. I know it releases the lock on the monitor it is waiting on, but I am not sure about other locks. The API does not indicate that. If you have documentation which says otherwise I would be interested in seeing it.
 
Puscas Marin
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steve Luke wrote:
Puscas Marin wrote:Well, http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Thread.State.html#BLOCKED tells us that " A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method or reenter a synchronized block/method after calling Object.wait. ". I just can't think of another reason for such a scenario aside from a competing thread getting hold on that same lock our BLOCKED thread has been previously waiting on.

Right, but your question was, how could a thread be blocked when no other thread holds the lock. So my question is: why did you ask this question? What makes you think it is possible, when the rules say it isn't?


If our thread A is indeed BLCOKED due to thread B getting lucky and acquiring (getting hold of) the lock A has been waiting on, it comes natural to me that thread dump should report that lock as 'acquired by thread B'. But thread dump contains no other RUNNABLE / WAITING threads that actually hold that lock. Thus, why is A BLOCKED since no thread haas acquired the lock A is blocked on ? Waht is keeping it from acquiring that lock... ?

And that thread shoud be in a RUNNABLE state - as soon as it switches to (TIMED) WAITING it releases all locks it holds. That means our BLOCKED thread will start running. Or stay blocked because another BLOCKED thread would acuqire that lock first.

It could be blocked on a different lock. A timed wait does not necessarily release all (or any) of the locks it holds (example, Thread.sleep() puts the thread into a timed wait and does not release any locks). I would also question weather waiting releases all locks it holds. I know it releases the lock on the monitor it is waiting on, but I am not sure about other locks. The API does not indicate that. If you have documentation which says otherwise I would be interested in seeing it.


I guess I am loosing it. Yes, only the last lock gets released, and Thread.sleep does not let go of anything. However, the previous question remains.

Thanks!
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
you should not be looking at just runnable threads to see who holds the lock. Look at all threads that are not new or terminated. I would almost guarantee the problem you are seeing is a deadlock caused by Thread A blocking on lock 1 because Thread B has lock 1 but is blocking on lock 2, which another Thread (maybe Thread A, maybe something less direct) holds.
 
Puscas Marin
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wait a minute .. it might have been that TDA tool reporting with no regard to reality. BRB
 
Puscas Marin
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at tigase.util.PriorityQueueRelaxed.take(PriorityQueueRelaxed.java:199)
- locked <0x0000000571e35a78> (a tigase.util.PriorityQueueRelaxed)


0x0000000571e35a78 appears only once in the whole thread dump. Captured with jstack this time, not TDA. Still, I am missing something :|
 
udaykiranreddy.d desam
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I want to know if we have a thread in blocked state is there any way to analyze for which thread it is waiting

java.lang.Thread.State: BLOCKED (on object monitor)
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!