How does read() blocking works?

Question

For some time I've been studying through Streams and Sockets in Java. What everyone says is that read() blocks (especially in sockets where the net is far slower than our computer). I am trying to imagine how this works. I mean does it look like :

(PSEUDOCODE)
read() {
    while (true) {
        if (there is at least one byte to read) {
            return this byte;
        }
    }
}

Or it has to do with other low level stuff? I assume Streams in Java are implemented in C/C++. My questions are, first how read() works and second does our thread get any kind of "sleep" when on read? I mean a while(true) is a waste for CPU cycles and I am wondering if the thread that blocks on read() gets notified by another thread "Hey your bytes are ready!" Thanks in advance.

The InputStream class documentation specifies that each subclass provides it's own implementation for the `read()` method. If you look at the implementations, you will see that usually there is a call to a native method which handles it. I assume that it has to do with the fact that the low level OS functions are more efficient at handling this kind of operations. — Slimu, Mar 17 '17 at 10:37
I think that kind of busy waiting using `while(true){}` is very inefficient and an asynchronous notification system should be in place for signaling when data is available. — Slimu, Mar 17 '17 at 10:42
The thread is not on "sleep" it is blocked waiting for IO and will be only scheduleable again after the block is lifted. There will be no spin-wait. All that is handled by (mostly native) JVM code. — Fildor, Mar 17 '17 at 10:42

score 0 · Answer 1 · answered Mar 17 '17 at 10:27

The underlying data source for some implementations of InputStream can signal that the end of the stream has been reached, and no more data will be sent. Until this signal is received, read operations on such a stream can block.

For example, an InputStream from a Socket socket will block, rather than returning EOF, until a TCP packet with the FIN flag set is received. When EOF is received from such a stream, you can be assured that all data sent on that socket has been reliably received, and you won't be able to read any more data. (If a blocking read results in an exception, on the other hand, some data may have been lost.)

Other streams, like those from a raw file or serial port, may lack a similar format or protocol to indicate that no more data will be available. Such streams can immediately return EOF (-1) rather than blocking when no data are currently available. In the absence of such a format or protocol, however, you can't be sure when the other side is done sending data.

Thanks for answering, but your answer covers about the half of my question. If you can be more specific to answering my questions. I would really appreciate it. — tur1ng, Mar 17 '17 at 10:32

score 0 · Answer 2 · answered Mar 17 '17 at 10:44

in my mind ,like the System.in ,when you use it like this new Scanner(System.in).nextInt() .the main Thread wait for a input from the console,sleep. when you input something the InputStream System.in get the data and into our program.if the date end you can got a flag and do something to prevent your work from exception .i'm new here,if it do not help ,sorry :-D

score 0 · Accepted Answer · answered Mar 17 '17 at 10:49

This is what the javadoc says:

Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown.

It says it blocks the thread/call, until data is available. As per the thread life cycle, following is true:

If a Thread is blocked in a blocking method it remain in any of blocking state e.g. WAITING, BLOCKED or TIMED_WAITING.

Also, suspended or blocked threads do not consume any cpu time. So, it's safe to say that this block is equivalent to calling wait() method on thread, and it will be notify()'d once data is available (Thread does not release locks/CPU if sleep is called, but you can't notify a sleeping thread which rules out possibility of thread entering into sleep in read method).

Here's openjdk code for read method. As it calls native method, it's not entirely clear how a thread is blocked. However, based on documentation and behavior of sleep vs wait, we can say that it enters into WAITING state and does not consume CPU.

it seems a/c to https://stackoverflow.com/questions/48968984/java-threads-state-when-performing-i-o-operations , thread is in runnable state during IO. — user3247895, May 20 '23 at 03:39

How does read() blocking works?

3 Answers3