[concurrency-interest] Proposal for Hybrid Threading Model and simpler Async IO
ron.pressler at gmail.com
Fri May 9 09:06:47 EDT 2014
Hi Doug, Joel, and all.
As others have mentioned, Quasar does indeed implement true fibers (just
like Go) on the JVM, and abstracts them, along with plain Java threads as
something called Strand, so that various constructs work equally well
whether run in a thread or a fiber. Coroutines are currently implemented at
the bytecode level with compile time/load time instrumentation, and fibers
are coroutines scheduled on an async FJPool. See this blog post:
I've linked to on this mailing list before).
Fibers preserve identity, and context (ThreadLocals). Also, we have a very
simple mechanism that turns any asynchronous, callback-based API, to a
fiber-blocking one (it's all open source).
With respect to Doug's concern over resource misuse, Quasar would warn you
if a fiber is taking too much CPU time, or if it's accidentally blocking
the underlying kernel thread.
While constructs like composable futures (and other monads) do make APIs a
easier to use, they essentially recreate the concept of the thread by
providing another way to say "block until this happens, and then do that".
We don't need this abstraction because we already have one. We just need a
different implementation. That's why people like Go and Quasar.
However, we would very much like to see fibers at the JVM level. Doug, I
realize that this is a huge undertaking, but is it something you would
consider as a JSR? What would be the timeframe for implementation in your
On Fri, May 9, 2014 at 3:43 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 05/07/2014 11:54 AM, Joel Richard wrote:
>> Quick update: The original thread was resurrected and Jeremy Manson from
>> wrote that they are implementing something quite similar internally
>> Before I
>> reinvent the wheel, I am trying to find out if is interested to share his
>> research and concept. That would help a lot and could even decide whether
>> or not
>> this will ever be implemented officially in the JVM.
> Sorry for delays in addressing this.
> Backing up first: Providing lighter-weight thread-like constructions
> has been a focus of attention in concurrency for a few decades.
> The main idea of the JDK5 java.util.concurrent.Executor
> framework was to decouple the notion of parallel execution
> from contextual details that might vary (processes vs threads
> vs tasks vs even FPGA or GPGPU strands). This works perfectly
> if Executors can enforce their contextual usage constraints,
> which they often either cannot do or choose not to do.
> Usually, they just tell people to please not use Thread
> methods or ThreadLocals, and in some cases like ForkJoin-related
> classes tell people to please not block. This doesn't always
> work out well because users do not want to change their
> Thread-based code to use alternative constructions. And it
> is hard to create alternatives for all possible ways to block
> threads. (See the nested stream parallelism discussion on
> this list for one case in point.)
> There are (at least) two ways to try to address this. One is as
> you suggest, to swap Thread stacks on blocking operations.
> Another is to generate another thread to perform any available
> work while the original thread blocks. ForkJoinPool uses
> a form of this. It is in general a safer move, because
> it preserves the relationship between threads, thread-locals,
> and stacks assumed by other user and VM code. Plus it tolerates
> cross-VM dependencies in which both a thread and its continuation
> must make progress, which can occur when blocking is due to IO
> representing message sends across cooperating processes on
> different machines, that might otherwise lock up.
> However, as we've found, even the "safe" strategy for doing this
> is not a cure-all. Whether done via new threads of new stacks,
> we have found that it is possible (and not rare) for users to
> write code that leads to unchecked resource use -- positive
> feedback-like loops in which an unbounded number of threads/stacks
> must be created. For ForkJoinPool, the best practical alternative
> appears to be to limit to constructing the minimal resources that
> ensure liveness.
> FWIW, I'm encouraged that the concurrency support community is
> slowly but surely discovering ways of supporting usages that
> avoid the underlying problems to begin with. For example,
> as Jeremy Manson noted, most programmers tend not to like most
> async and non-blocking IO APIs. But most programmers seem to like
> the non-IO-oriented (CompletableFuture+lambda), and similar
> (and layerable) Promise- Reactive /Rx-, async-actor-based extensions.
> So we plan to further improve and integrate these for JDK9.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest