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

√iktor Ҡlang viktor.klang at gmail.com
Mon May 5 08:55:42 EDT 2014

Hi Joel,

In case you haven't already, I recommend to have a look at Scheduler
Activations: http://en.wikipedia.org/wiki/Scheduler_activations

On Mon, May 5, 2014 at 1:55 PM, Joel Richard <ri.joel at gmail.com> wrote:

> 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.
> I agree, this would change the performance and even more the scalability
> model, but I think that would be something positive 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. Therefore 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. 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
> _______________________________________________
> 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/a49ffa77/attachment.html>

More information about the Concurrency-interest mailing list