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

Joel Richard ri.joel at gmail.com
Mon May 5 15:42:11 EDT 2014


My idea goes far behind such frameworks. First of all, it will provide a
new threading model and secondly, it should enable to run existing blocking
IO libraries asynchronously without changing code. Unfortunately, none of
the mentioned frameworks can achieve that. Right now I am thinking about
whether it would be possible to implement something with Java agents and
instrumentation, but I fear that the performance wouldn't be the same as if
it were implemented natively.


On Mon, May 5, 2014 at 5:58 PM, Jan Kotek <discus at kotek.net> wrote:

>  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.
>
>
>
> Jan
>
>
>
> On Sunday, May 04, 2014 13:06:22 Joel Richard wrote:
>
> Hi,
>
>
> 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.
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140505/273fe5fd/attachment.html>


More information about the Concurrency-interest mailing list