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

Joe Bowbeer joe.bowbeer at gmail.com
Tue Aug 9 11:09:23 EDT 2011

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
>> > switches for its actors. The way they did it is by using a modified
>> version
>> > of Kilim , which uses bytecode instrumentation to implement
>> > 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
>> > 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
> Experts
> Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110809/db18fea5/attachment.html>

More information about the Concurrency-interest mailing list