What is the thread state of a Blocking I/O operation

Question

I have the following code which execute a DB call within a reentrant lock. This code is executed by a thread pool (ExecutorService). As my knowledge this scenario is a blocking I/O operation. But I'm confused about the thread state while it executing the DB call and returning the result. Some says it's in a blocking state, some says it's in a waiting state with a monitor(But I think thread release the monitor when it's in waiting state). Need a clarification on this.

@Override
public void run() {
    lock.lock();
    try {
       // DB call
    } finally {
        lock.unlock();
    }
}

AFAIK threads have three states. "Ready", "Running" and "Blocked". I'm not sure what a waiting state is. There may be such a state, technology advances and sometimes there's stuff I haven't learned yet. But your thread while it is "executing" should be Running, and while waiting for IO should be Blocked. If the thread is able to run (not blocked) but another thread is using the CPU, then it's Ready. — markspace, May 06 '19 at 15:47
see [How does I/O-methods like read() put a Thread in blocked state in java?](https://stackoverflow.com/q/41141834/217324), answer shows thread state when doing blocking I/O — Nathan Hughes, May 06 '19 at 19:12

markspace · Answer 1 · 2019-05-07T14:51:17.150

But I have heard threads that moves to waiting pool releases the lock it acquired. So how it applicable in this scenario ?

I think this is "no." The locked status of lock shouldn't be affected by the status of some other object's monitor. The lock on lock should be held until the routine executes completely, even if its thread is blocked and waiting on IO, lock will still be locked and block all other threads until it finishes and releases the lock.

The difference here is that you're not doing a wait on lock. lock.wait() would release the lock, but your routine will actually block (and wait) on some other IO object, so lock isn't affected.

score -1 · Answer 2 · answered May 06 '19 at 15:17

-1

Blocking state is when waiting for a monitor lock.
Waiting is when waiting for another thread.

Since here the thread is waiting for DB request to respond, it is waiting, not blocked.

See details about thread states in Java here.

answered May 06 '19 at 15:17

displayName

13,888
8
60
75

1

"Waiting" appears to just be a special case of being Blocked. It looks like a detail of the Java implementation. If one is viewing the thread from the OS level, I'd expect it to show as Blocked. Good link though, the details of Java's implementation are interesting. – markspace May 06 '19 at 15:50
2

So how is that a clear answer to the question? The question is: What is the thread state **while it executing the DB call** and returning the result. Since neither option you listed cover that, it's not really that helpful. – Andreas May 06 '19 at 15:51
So does that mean it (thread) will release the lock until a response received from DB ? – Sidath Bhanuka Randeniya May 06 '19 at 15:53
1

@SidathBhanukaRandeniya: Of course not. Lock will be released only after the code for release is executed, which will happen only when thread reaches the finally block. – displayName May 06 '19 at 15:56
@Andreas: I assumed that by "while it executing the DB call and returning the result", OP meant that the thread has made the call and is waiting for the DB to finish execution and return the result. We can ask for clarification if that's not the case. Alternatively, you can add an answer assuming otherwise. – displayName May 06 '19 at 16:03
@displayName your assumption is correct. But I have heard threads that moves to waiting pool releases the lock it acquired. So how it applicable in this scenario ? Or is it not valid for reentrant/Synchronized blocks ? – Sidath Bhanuka Randeniya May 06 '19 at 16:11
@SidathBhanukaRandeniya: Can you please add some link about it? If I understand correctly, the thread will not release the lock in the middle of the execution. It will release locks when there are more locks that it has to acquire *before* it can begin execution, but cannot. In that case, it would release the locks it acquired so far to prevent deadlock. – displayName May 06 '19 at 16:35
@displayName Refer the following answers. However in these scenarios they have called wait method deliberately upon the thread inside synchronized block. https://stackoverflow.com/questions/1036754/difference-between-wait-and-sleep – Sidath Bhanuka Randeniya May 06 '19 at 16:58
I read "while it executing the DB call and returning the result" as one of the `executeXxx()` method of `(Prepared)Statement`, or higher-level equivalent (e.g. JPA). – Andreas May 06 '19 at 17:23
@Andreas Actually I'm interested in the state of the thread which execute the code snippet. If thread goes to waiting state will the lock be released ? I have a contrary understanding of waiting state in above scenario. – Sidath Bhanuka Randeniya May 06 '19 at 19:00
1

@SidathBhanukaRandeniya No, why would the lock be release? It's only released when you call `unlock()`. The status of the lock has nothing whatsoever to do with the status of the thread. – Andreas May 06 '19 at 20:09

score -1 · Answer 3 · answered May 06 '19 at 20:17

... some says it's in a waiting state with a monitor(But I think thread release the monitor when it's in waiting state)

You are confusing monitors and locks.
See What's a monitor in Java?

Every Java object has a monitor. The monitor is "locked" when you synchronize on the object, and that lock is released when you exist the synchronized scope or while you wait() on the object.

A Lock is a totally different kind of mechanism where you explicitly call lock() and unlock().

What is the thread state of a Blocking I/O operation

3 Answers3