10
votes

For me below are the most probable definitions for asynchronous and non-blocking I/O:

Asynchronous I/O: In asynchronous I/O applications return immediately and OS will let them know when the bytes are available for processing.

NON-blocking I/O: Here application returns immediately what ever data available and application should have polling mechanism to find out when more data is ready.

After knowing these definitions if we analyze java channels i.e. SocketChannel, ServerSocketChannel, DatagramSocketChannel then we can find that these channels can be used as blocking or non-blocking mode by the method configureBlocking(boolean block). and assume that we are using them as non-blocking mode. So here comes the questions:

if i will use Selector i.e. register channels to a selector whether it is Asynchronous I/O or NON-blocking I/O?

I feel this is Asynchronous I/O in java if and only if underlying operating system is informing the java application about readiness selection of a channel. Else it is non-blocking I/O and selector is just a mechanism which helps us polling the above mention channels as i mention in the definition. Which is correct? Thanks in advance.

EDIT:

I have answered one part of the question i.e. types of I/O and how java facilitates these functionality.

But one question still remains whether all these functionalities are provides by java is simulated at java layer or it uses underlaying OS to facilitate? Assume the underlaying OS has all the support for these functionalities.

Please refer to the answer.

2

2 Answers

15
votes

I thought of answering my question by doing some more homework. This post will also help in understanding the I/O concepts w.r.t. underlying OS.

  • This is blocking I/O: FileInputStream, FileOutputStream and even reading to or writing from Socket come under this category

  • This is non-blocking I/O: this is used by Socket Channels like ServerSocketchannel, SocketChannel, DatagramChannel in Java

  • This is multiplexed I/O: in Java it is used by Selector to handle multiple channels and these channels should be non-blocking by nature. So Socket channels can be registered to Selector and Selector can manage by I/O multiplexing facility of underlaying OS.

  • Now comes Asynchronous I/O. In asynchronous I/O applications return immediately and OS will let them know when the bytes are available for processing. In java it is facilitated by AsynchronousSocketChannel, AsynchronousServerSocketChannel, AsynchronousFileChannel.

For these above functionalities java uses underlying OS heavily. This is evident when i was going through the book . Here in chapter 4 the author mentions that

True readiness selection must be done by the operating system. One of the most important functions performed by an operating system is to handle I/O requests and notify processes when their data is ready. So it only makes sense to delegate this function down to the operating system. The Selector class provides the abstraction by which Java code can request readiness selection service from the underlying operating system in a portable way.

Hence it's clear that Java uses underlying OS heavily for these features.

2
votes

if i will use Selector i.e. register channels to a selector whether it is Asynchronous I/O or NON-blocking I/O?

The channels are doing non-blocking I/O. The Selector itself is doing multiplexed I/O. Asynchronous I/O in Java is done via Futures, and in other languages via semaphores or callbacks.

But one question still remains whether all these functionalities are provides by java is simulated at java layer or it uses underlaying OS to facilitate? Assume the underlaying OS has all the support for these functionalities.

The operating system does it. Applications can't, and Java qualifies as an application to the operating system.