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

Joe Bowbeer joe.bowbeer at gmail.com
Tue Aug 9 11:16:03 EDT 2011

Ah, sorry, I was familiar with continuations, but not with CPS

Is there a favorite reference you can recommend?
On Aug 9, 2011 8:09 AM, "Joe Bowbeer" <joe.bowbeer at gmail.com> wrote:
> What? No chickens?
> Do you mean CSP - communicating sequential processes?
> On Aug 9, 2011 2:28 AM, "√iktor Ҡlang" <viktor.klang at gmail.com> wrote:
>> 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
>>> > 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
>>> 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
>> Experts
>> Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110809/e839c0e9/attachment.html>

More information about the Concurrency-interest mailing list