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

Ron Pressler ron.pressler at gmail.com
Fri May 9 08:53:50 EDT 2014


Quasar gives you fiber-blocking NIO by implementing the blocking NIO API
using async NIO under the covers.


On Mon, May 5, 2014 at 12:03 AM, Joel Richard <ri.joel at gmail.com> wrote:

> That is a really interesting project. Thank you very much for mentioning
> it.
>
> As far as I can see, the missing part is that it cannot transform thread
> blocking IO into fiber blocking IO (which is asynchronous) yet. Maybe even
> that could be implemented partially, if it replaced the most important
> blocking classes of the Java standard library while loading with an
> equivalent non-blocking version (based on NIO). This would be fantastic for
> a proof of concept of my initial idea since it wouldn't require any changes
> in the native C code.
>
> @Ron, I hope it's ok for you that I have added you to this thread. Have
> you thought about this before? Could you imagine that this would work?
>
> Regards, Joel
>
>
> On Sun, May 4, 2014 at 6:39 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>
>> See Ron Pressler's work
>>
>>
>> http://cs.oswego.edu/pipermail/concurrency-interest/2013-October/011900.html
>>
>>
>> http://cs.oswego.edu/pipermail/concurrency-interest/2014-February/012347.html
>>
>> which I think is definitely the way to go. Other schemes - callback,
>> future/promise, generator, even C#'s async - are just DSLs trying to
>> simulate the threading model, imperfectly. If threads were lightweight
>> to begin with, these solutions would not have been invented.
>>
>> Zhong Yu
>>
>>
>>
>> On Sun, May 4, 2014 at 6:06 AM, Joel Richard <ri.joel at gmail.com> 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/20140509/ac5067e4/attachment-0001.html>


More information about the Concurrency-interest mailing list