35

There seems to be a discrepancy between SO consensus and nearly every Java thread state diagram on the Internet; specifically, regarding thread state transition from WAITING after notify() or notifyAll() is invoked...

  • WAITING never goes directly to RUNNABLE
  • The thread is WAITING until it is notified...Then it becomes BLOCKED...
  • Once this thread is notified, it will not be runnable...This is..Blocked State.

So the concensus on SO is: a thread transitions from WAITING to BLOCKED after invoking notify() or notifyAll(); diagram below illustrates this transition in green.

Question

Why do most state diagrams on the web illustrate the transition from WAITING to RUNNABLE, not BLOCKED? Depiction in red shows the incorrect transition; am I missing something?

enter image description here

Community
  • 1
  • 1
raffian
  • 31,267
  • 26
  • 103
  • 174
  • 1
    Why would I ask the person who drew the diagram when based on your comment they don't know better? :-) – raffian Feb 07 '15 at 14:56
  • I said "don't or didn't". If you ask them, they may discover that they are wrong. Or they may already have discovered. – Stephen C Feb 07 '15 at 15:04
  • So you're saying my diagram is more accurate than roughly 106,000 Google results? Hellulalua! – raffian Feb 07 '15 at 16:51
  • No. I doubt that there are 106,000 different state diagram images on the web ... – Stephen C Feb 07 '15 at 22:59
  • 3
    If that is the case, what is special with `TIMED_WAIT` ? why it is directly going back to `RUNNABLE`, instead of moving to `BLOCKED` ? – Manu Oct 06 '15 at 06:14
  • 1
    there are some clearer answers, if you need. https://stackoverflow.com/q/15680422/2361308 – Hearen May 18 '19 at 11:21

4 Answers4

26

Any diagram that shows a notify invocation bringing a thread from WAITING to RUNNABLE is wrong (or is using an unclarified shortcut). Once a thread gets awoken from a notify (or even from a spurious wakeup) it needs to relock the monitor of the object on which it was waiting. This is the BLOCKED state.

Thread state for a thread blocked waiting for a monitor lock. 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.

This is explained in the javadoc of Object#notify():

The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object.

and Object#wait()

The thread then waits until it can re-obtain ownership of the monitor and resumes execution.

Sotirios Delimanolis
  • 274,122
  • 60
  • 696
  • 724
  • 1
    Makes sense. But, surely that's true of `TIMED_WAITING` too then? – mystarrocks Jun 06 '16 at 02:05
  • Except if it has entered the `TIMED_WAITING` state due to `sleep(t)` that is. – mystarrocks Jun 06 '16 at 02:20
  • 3
    @mystarrocks According to the [`Thread.State` javadoc](http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.State.html#BLOCKED), `WAITING` is for the parameterless `Object#wait`, while `TIMED_WAITING` is for the overload that accepts a wait time. Yes, this applies to both. Concerning `sleep`, a thread doesn't unlock any held monitors, it still owns them by the time it wakes up. – Sotirios Delimanolis Jun 06 '16 at 04:53
2

A thread is in WAITING state goes in BLOCK state,until it acquires monitor by notify and become RUNNABLE.

Same applies for TIMEDWAITING,it goes in BLOCK state,if monitor is hold by some other thread,even though specified time has passed.(your diagram need to be corrected)

0

I am focusing on the problem recently.

as the Oracle document Thread.State says we can use LockSupport.park() to put the current thread into 'WAITING' or 'TIMED_WAITING' state.

so when you try the LockSupport.unpark(), the specified thread will return to 'RUNNABLE' from 'WAITING'/'TIMED_WAITING'. (I am not sure whether it will go through the 'BLOCKED' state)

hgfeaon
  • 71
  • 1
  • 2
  • I think LockSupport.unpark() will cause the specified thread state changing from WAITING to RUNNABLE directly. – Qoobee May 14 '20 at 05:39
0

It is worth to mention that is also true for Thread.interrupt() method during WAITING state while in lock.wait() method.

Thread.interrupt() method will firstly make WAITING thread BLOCKED with isInterrupted flag set to true, and only after reacquiring lock interrupted thread will be able to throw InterruptedException (that is obvious, as it cannot handle exception, by that continuing execution without having exclusive lock before). (example here)

Simply to say

Always WAITING -> BLOCKED to be able again compete for the lock, and after that to acquire it eventually and run its' code RUNNABLE.

Alex
  • 3,923
  • 3
  • 25
  • 43