1

I was going through the twitter finagle library which is an asynchronous service framework in scala and I have some question regarding asynchronous libraries in general.

So as I understand, the advantage of an synchronous library using a callback is that the application thread gets free and the library calls the callback as soon as the request is completed over the network. And in general the application threads might not have a 1:1 mapping with the library thread.

  1. The service call in the library thread is blocking right?
  2. If that's the case then we are just making the blocking call in some other thread. This makes the application thread free but some other thread is doing the same work. Can't we just increase the number of application threads to have that advantage?

It's possible that I mis-understand how the asynchronous libraries are implemented in Java/Scala or JVM in general. Can anyone help me understand how does this work?

Piyush
  • 321
  • 2
  • 13

1 Answers1

2

Async approach is useful abstraction: your CPU-intensive thread offloads long-running IO operation to dedicated (maybe, belonging to a library) thread. When IO is done, some other thread will receive IO result.

Using blocking approach, you'll miss CPU ticks for your threads which are doing blocking IO call. And adding some more threads to ensure there's always free thread to do some CPU work means wasting OS/JVM resources for re-scheduling.

Blocking IO is used because it's simpler to program (no need to synchronize caller and callback).

Actually, IO is only one possible use-case where async style is useful. In general, whenever you feel that task at hand will benefit from splitting it into several activities, which can be run concurrently and would communicate with each other, this is the case for async style. Examples not connected to IO:

  • GUI: GUI event loop thread passes user input to background threads, and they do necessary processing;
  • Utilizing modern multi-core CPUs: if your task can be split in several subtasks, you can run these in separate threads, utilizing all available cores. Naturally, you'll need to gather results of subtasks, and you'll need async style here.
Victor Sorokin
  • 11,878
  • 2
  • 35
  • 51
  • 1
    blocking/non-blocking IO != asynchronous. – vptheron Oct 09 '14 at 19:25
  • So the I/O operation is still blocking for the library thread right? – Piyush Oct 09 '14 at 20:01
  • Well, yes (because what can that thread do else while packets go over the network?) Good news, is that thread can be blocked waiting for _some_ IO operation from _a set of IO requests_ to finish, using Java NIO (selectors). Thus, single JVM thread will handle several IO requests. – Victor Sorokin Oct 09 '14 at 20:10
  • Can you elaborate a bit more on how a single JVM thread handles several I/O requests? Or point me to some documentation online. – Piyush Oct 09 '14 at 20:21
  • 1
    Wikipedia has nice overview and links to JDK javadocs: http://en.wikipedia.org/wiki/Non-blocking_I/O_(Java) – Victor Sorokin Oct 09 '14 at 20:25
  • synchronous calls in code can also be non-blocking under the hood; i.e. they block the logical (green) thread but not an OS thread. perhaps not in Java tho, without JVM sorcery. – Erik Kaplun Oct 09 '14 at 21:27
  • Operating systems provide direct non blocking asynchronous IO facilities, I would hope that the JVM is using those. See Windows/Solaris IO completion ports, and I am sure linux/bsd has something similar. – experquisite Oct 12 '14 at 10:56
  • So the basic idea is that there will be common thread which will do I/O for multiple threads at once and will call the callback methods accordingly. Is this understanding correct? Also is this how Future class is implemented in Java? – Piyush Oct 21 '14 at 21:05
  • There may be single IO thread serving multiple IO reqs (`Selector` in Java NIO), maybe correspondence is one IO thread - one IO operation (traditional Java IO). Now, another use-case I forgot to mention is GUI thread offloading user input to background thread -- this async execution too. No I/O involved here. Generally, whenever you think you will benefit from having some concurrent activities which are going to communicate with each other, you naturally want to use async programming. – Victor Sorokin Oct 21 '14 at 21:20
  • @piyush Copied my prev comment into answer's body. – Victor Sorokin Oct 21 '14 at 21:36