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

David Holmes davidcholmes at aapt.net.au
Mon May 5 16:08:36 EDT 2014

Joel Richard writes:
> Yes, my intent is to implement a M:N hybrid threading model; 
> however, I think it could co-exist with the existing 1:1 model. I 
> would suggest that the lightweight threads don't switch 
> automatically until they block or call Thread.yield (similar to 
> Node.js). Therefore, the M:N model would be great for servers 
> while the 1:1 model might still be better suited for 
> computational tasks or precise timers. In order that library 
> developers don't have to know whether their code is running in a 
> native or in a lightweight thread, it would make sense to create 
> some utilities, e.g. one which executes computational tasks in a 
> worker thread if the current thread is just a lightweight thread. 
> Moreover, some methods would change their behavior (without 
> breaking the API) if they are executed in lightweight threads. 
> For example, Thread.yield would rather just start/continue 
> executing another task instead of switching to another thread.

Conceptually you may be able to have a system where a M:N scheduler co-exists with a 1:1 scheduler; but I do not think you can simply add that to hotspot without completely rewriting the existing code. Further, trying to generalize a M:N model to apply to all threads is extremely difficult - how exactly do you pick up another thread and when can you return to the original? Specialized approaches, like ForkJoin, define the computational chunks so that it is easy to do this. There are also issues with thread identity that would have to be handled somehow.
> I agree, this would change the performance and even more the 
> scalability model, but I think that would be something positive 

Can you back that up with any numbers? "Words are wind ..." ;-)

> and bring a lot of opportunities - especially for application 
> servers. If I am not mistaken, the JVM doesn't guarantee a 
> certain performance characteristic or thread behavior.

It may not guarantee it but we go to a lot of trouble to try and not introduce discontinuities in the performance curves. People invest a lot of time and effort in tuning large apps, and in designing them for the way things actually work. You can't completely change the threading and performance model for these apps.

> and since lightweight threads would be an optional feature, I 
> think this should be considered as a chance to make Java and the 
> JVM future proof without re-implementing hundreds of libraries. 

Are you saying that the VM is either started in traditional mode, or else this new mode? That would address the compatability issue - provided you can implement the new mode without changing the existing performance model.


> It would make async IO and scalable servers easier than with 
> Node.js and prevent that companies switch from Java to Go (or 
> similar languages) just because they have a more appealing 
> concurrency model right now.
> Regards, Joel
> On Mon, May 5, 2014 at 9:20 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:
> On May 4, 2014, at 11:37 PM, Gregg Wonderly <gregg at wonderly.org> wrote:
> > 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.
> I believe the idea for Green Threads stems from lightweight 
> threads in Solaris. There, a lightweight thread ran on top of a 
> single kernel thread. The kernel thread time sliced between each 
> of it’s LWP. I’m not sure it ever worked all that well as CPU’s 
> at the time of inception weren’t quite what they are today and 
> scheduling in Solaris always felt sluggish.
> >
> > 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.
> Completely agree, copies are always going to be a problem and 
> immutability can only be part of the answer.
> Regards,
> Kirk

More information about the Concurrency-interest mailing list