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

Joel Richard ri.joel at gmail.com
Mon May 5 07:55:29 EDT 2014


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140505/97a676d9/attachment-0001.html>


More information about the Concurrency-interest mailing list