[concurrency-interest] Proposal for Hybrid Threading Model and simpler Async IO

Jan Kotek discus at kotek.net
Mon May 5 11:58:51 EDT 2014

For networking there are many projects for Async IO and lightweight threads. 
Checkout Akka, Verte.x, Actors...

I hope to implement async database one day. But for disk io there  is only 
AsynchronousFileChannel which has too much overhead.


On Sunday, May 04, 2014 13:06:22 Joel Richard wrote:


Recently I have researched a little about how different languages implement async 
IO because I wanted to implement a high scalability web server. When I looked at 
Google Go, I realized that the common callback approach is actually just a language-
level workaround to fix a VM limitation. 

So I wondered whether and how it could be possible to implement something 
similar to goroutines for the JVM. Here are my thoughts: There should be an 
ExecutorService implementation which executes tasks in a special mode. If you use 
any (so far) blocking methods (like Thread.sleep, network/file system IO, 
Object.wait and synchronization) in such a task it uses however not the blocking 
native implementation, but an non-blocking version of it. While it waits for the 
method to complete, it can continue with another task in the same native thread. 
This means that all tasks can share a small native thread pool. If longer 
computations have to be done, the developer can either call Thread.yield() from 
time to time or just move the computation to a classical thread. 

With such an approach it would be much easier to write highly scalable server 
software* and it would make it even possible to run most existing libraries with 
minimal changes as asynchronous IO libraries. Basically, they would just have to 
make sure that they call Thread.yield() in longer computationally intensive loops and 
don't start additional normal threads. Last but not least, the behavior of existing 
threads wouldn't be changed at all. 

* The advantage of async IO compared to blocking IO is that it doesn’t require 
expensive thread context switches and that it needs less memory (because fewer 
threads allocate less memory for stacks). 

As mentioned above, this would require implementing an asynchronous version of 
all blocking native methods. I am not that familiar with JNI nor C, but I think this 
could by achieved by allowing the developer to define a second C function with the 
_async suffix which calls a callback instead of returning a value. If the Java native 
method is called in a normal thread, the old C function is called and otherwise the 
_async version of it. Since Java already supports async IO with NIO, I think it should 
be technically possible to implement asynchronous versions for almost all of the 
currently blocking native functions. If an operating system doesn't support certain 
non-blocking operations, it could just block a special thread instead (as far as I 
know Go does it similar). 

I am aware that the required changes would be complicated, but I think it is worth a 
discussion since concurrency, non-blocking IO and high scalability will be even more 
important in the future. This feature would make it much easier to fulfill such 
requirements. For example, it would not be necessary anymore to create a second 
version of each so far blocking API. Also all standardized APIs like JDBC or JPA would 
suddenly all have a non-blocking implementation. The amount of work which could 
be saved would be enormous. 

What do you think about this idea? Has something like that been discussed before?

Regards, Joel

PS I sent a similar email first to the jdk9-dev because I wasn't sure which mailing list 
to use. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140505/31681f45/attachment-0001.html>

More information about the Concurrency-interest mailing list