How is a thread in blocked state caused by waiting on a objects lock handled by the JVM

Question

I have seen there are different ways a thread could get to blocked state. I'm interested to know what exactly happens after a thread is in blocked state. How does it get back to running state?

If its blocked by sleep(time) then it moves to the runnable queue after time milli secs. If its blocked on a I/O operation it gets into the runnable queue once that is done.

How does it get to the runnable queue when it is waiting on an objects lock? How does it know that the lock on the object its waiting for is now available? Can some one also explain the internals of how the blocked thread on I/O works?

Please correct me if my understanding on any of the above topics isn't right..

aioobe · Answer 1 · 2011-01-25T14:32:17.560

How does it get to the runnable queue when it is waiting on an objects lock?

If the thread is blocked due to trying to enter a synchronized block, the thread is automatically marked as runnable when the other thread (holding the lock) releases the lock by exiting from a synchronized block of the same object.

If the current thread is blocked due to a call to someObject.wait(), the thread is "released" when another thread calls someObject.notify().

On the bytecode level it looks as follows:

[load some object, obj, onto the operand stack]
monitorenter  // grab the lock

// do stuff

[load obj onto the operand stack again] 
monitorexit   // release the lock

If someone else already holds the lock of obj, the thread will hang on monitorenter until the other thread calls monitorexit.

The exact details of how monitorenter and monitorexit should be implement is not specified by the JLS. That is, it is JVM/OS dependent.

For further details, refer to JLS Wait Sets and Notifications.

Suppose there are some threads in Ready state (i.e. not running but runnable) and some threads in blocked state waiting to acquire the same lock. Once that lock is released by the running thread, is it possible that, a thread from Ready state is moved to Running state and then it acquires the released lock after some execution and threads in Blocked state did not got the chance here to reacquire the released lock ? — Number945, Nov 22 '21 at 02:35

score 0 · Answer 2 · answered Jan 25 '11 at 14:22

On a close-to-code level it looks like this:

Thread 1:

Object mutex = new Object();
....
synchronized(mutex) {
    //lock to mutex is acquired.
    mutex.wait(); //lock to mutex is released. Thread is waiting for somebody to call notify().
    doSomething();
}

Thread 2:

synchronized(Thread1.mutex) {
    //acquires the lock on mutex. 
    //Can be done only after mutex.wait() is called from Thread1
    // and the lock is released
    Thread1.mutex.notify(); // notifies Thread1 that it can be resumed.
}

In general you should keep in mind that Thread.sleep() holds the lock on the resources, but Thread.wait() releases the locks and can be notified by other Threads.

score -1 · Answer 3 · answered Jan 25 '11 at 14:23

-1

AFAIK JVM use native threads. So it is OS not JVM that manage thread schedule and context switching.

You can look at actual JVM source code. It's open.

answered Jan 25 '11 at 14:23

9dan

4,222
2
29
44

If you're explicitly referring to Suns/Oracles Hotspot JVM, you may want to clarify this. – aioobe Jan 25 '11 at 14:33
1

SO post about JVM source: http://stackoverflow.com/questions/2026093/is-jvm-open-source-code-if-not-how-can-i-get-code-of-jvm – 9dan Jan 25 '11 at 15:04

How is a thread in blocked state caused by waiting on a objects lock handled by the JVM

3 Answers3