[concurrency-interest] Fast control transfer from one thread to another?

√iktor Ҡlang viktor.klang at gmail.com
Tue Aug 9 05:18:32 EDT 2011

What about CPS transformation?

On Mon, Aug 8, 2011 at 10:24 PM, Charles Oliver Nutter
<headius at headius.com>wrote:

> On Mon, Aug 8, 2011 at 3:30 PM, Ron Pressler <ron.pressler at gmail.com>
> wrote:
> > If each fiber is represented by a thread, then any transfer of control
> > between fibers would require an OS task switch, which is bound to be
> slower
> > than C Ruby's lightweight threads. However, the erjang project has
> > implemented erlang on top of the JVM, and erlang requires lots of "fiber"
> > switches for its actors. The way they did it is by using a modified
> version
> > of Kilim , which uses bytecode instrumentation to implement continuations
> > with stack-capture - the same way C Ruby does it, I presume.
> This would work, but the execution performance of bytecode
> instrumentation would almost certainly be worse than what we have now.
> Kilim-style bytecode manipulation also only works if you can
> instrument all the code you're passing through (leaves excluded),
> which would mean almost all of JRuby would need to be instrumented in
> this way.
> I would also wager there's no change of inlining code that's been
> instrumented...or at least a large class of optimizations would not
> work in the presence of stack trampolines.
> > Scala uses java's Fork/Join tasks for its actor scheduling, and it sounds
> > like you might be able to use that too. You transfer control to another
> > fiber with fork, and block yourself with join.
> I'm essentially doing this now with park/unpark, but I'll look into
> whether Fork/Join makes it cleaner.
> > But in any case, for best performance you will probably have to abandon
> the
> > one-thread-per-fiber model (which is also expensive on memory)
> Yes, I'd love to :) But unfortunately there's no way to do that on the
> JVM right now.
> Perhaps this is a good time to lobby for concurrency-interest's
> support in Lukas Stadler's JVM coroutines. He implemented them for
> OpenJDK as part of his PhD work, and they provide much faster Fiber
> context-switching than even the C implementations of Ruby. I believe
> he's looking to launch a JSR soon...and it seems like
> pausable/resumable workers (in the form of coroutines) might be a
> useful feature for concurrency (especially atop blocking library calls
> that would steal a thread forever). Imagine having a worker pool that
> only has N threads for M > N running worker coroutines, and uses
> coroutine suspend/resume to choose between them as necessary.
> - Charlie
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110809/7a91719f/attachment-0001.html>

More information about the Concurrency-interest mailing list