[concurrency-interest] Proposal for Hybrid Threading Model and simpler Async IO
gregg at wonderly.org
Sun May 4 17:37:31 EDT 2014
The original version of Java used a runtime environment which used the term "Green Threads". This was of course taken out when sun started trying to make Java more than an Applet engine.
There are two problems. First is all the visibility and contention issues which the concurrency package has demonstrated to not be a simple issue due to rather arcane processor architecture issues.
What we actually need is infinitely fast cache and cache coherency algorithms, and much more sane processor designs which try to allow processors to work together rather than trying desperately to keep them from interfering with each other.
Sent from my iPhone
> On May 4, 2014, at 4:03 PM, 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
>> 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
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest