[concurrency-interest] Benchmark to demonstrate improvement in thread management over the years.
ron.pressler at gmail.com
Tue Aug 13 10:58:49 EDT 2013
Events and threads are duals, but their implementations have usually
favored different goals. The key implementation difference, I think, is
that OS threads (or Java threads for that matter) were designed to support
long-running computations, while events support processes that are expected
to block more often than not. But we can design lightweight threads that
support the same expectation, and I've done exactly that in a relatively
new library called Quasar <https://github.com/puniverse/quasar>. Quasar
implements true lightweight threads (which we call fibers) that are
implemented as continuations (instrumented at class-load time to manage a
dynamically resizing stack), scheduled on top of a fork-join pool.
The Fiber class has a very similar API to that of Thread, and, most
importantly, supports the "park" and "unpark" operations. We general
transformation from an asynchronous callback to a park-unpark pair,
exploits the event/thread duality, and transforms any asynchronous (i.e.
callback based) operation to a "fiber-blocking" operation. Quasar already
transforms NIO operations to fiber-blocking operations (currently through a
slightly modified API, but as soon as tomorrow, we will employ NIO's
original interfaces), and in a couple of weeks we'll release fiber-based
servlet (one fiber per request) + fiber-blocking JDBC. The goal is to
provide the scaling of the evented model with the ease of use of the
On Tue, Aug 13, 2013 at 4:47 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:
> CFS is an O(logN) scheduler since it represents the runqueue as a
> red-black tree (previous scheduler was O(1)). It keeps a reference to the
> leftmost leaf (next runnable task) so that removing from the tree is O(1)
> but after running it, it reinserts into the tree which gives logN.
> Sent from my phone
> On Aug 13, 2013 6:37 AM, "Kimo Crossman" <kimo at webnetic.net> wrote:
>> I thought current Linux scheduler CFS was O(1)
>> On Tue, Aug 13, 2013 at 1:49 AM, Kirk Pepperdine <kirk at kodewerk.com>wrote:
>>> On 2013-08-13, at 8:38 AM, James Roper <james.roper at typesafe.com> wrote:
>>> On Tue, Aug 13, 2013 at 2:59 PM, Unmesh Joshi <unmeshjoshi at gmail.com>wrote:
>>>> Hi James,
>>>> At what number of threads JVM or OS performance starts degrading? Or
>>>> number of threads start becoming the main bottleneck in the system?
>>> Really, you just need to do your own load testing specific to your own
>>> application, hardware and OS requirements. The current Linux scheduler
>>> runs in O(log N),
>>> Really? I thought it was using an O(N) heap sort. Anyways, IME, the
>>> bigger problem is that getting the thread scheduler scheduled so that you
>>> can get threads scheduled... (there might be a Dr. Seuss thing going on
>>> so technically, that means performance starts degrading at 2 threads,
>>> since every thread added increases the amount of time the scheduler takes.
>>> But of course, that degradation is negligible compared to the amount of
>>> time your app spends waiting for IO. So it all depends on your app, what
>>> it's doing, and what its requirements are.
>>> It's not just scheduling that gets impacted, another obvious one that I
>>> already I pointed out was memory consumption, so once the thread stacks
>>> have consumed all available RAM, then they won't just be the bottleneck,
>>> your application will slow to a crawl or even crash.
>>> Slow is something due to something else. No more stack space leads to
>>> OOME Stack space exhausted. Is this what you mean?
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest