[concurrency-interest] Proposal for Hybrid Threading Model and simpler Async IO
ri.joel at gmail.com
Mon May 5 16:06:07 EDT 2014
Thank you for the hint. The following article contains even more
interesting information: https://en.wikipedia.org/wiki/Thread_(computing)
With the terminology from there, I am just proposing to implement
coroutines in Java and execute all so far blocking calls asynchronously
(but only when executed in coroutines). That sounds already much better :-)
On Mon, May 5, 2014 at 2:55 PM, √iktor Ҡlang <viktor.klang at gmail.com> wrote:
> 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.
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest