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

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


On Tue, Aug 9, 2011 at 5:16 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> Ah, sorry, I was familiar with continuations, but not with CPS
> transformation.
>
> Is there a favorite reference you can recommend?
>
Scala has a CPS transformation compiler plugin. In Akka we've implemented
our Dataflow API using that:

Usage: http://akka.io/docs/akka/1.1.3/scala/dataflow.html#id3

the "flow" construct
https://github.com/jboner/akka/blob/v1.2-RC2/akka-actor/src/main/scala/akka/dispatch/Future.scala#L313

reading the value of a dataflow variable
https://github.com/jboner/akka/blob/v1.2-RC2/akka-actor/src/main/scala/akka/dispatch/Future.scala#L363

writing the value of a dataflow variable
https://github.com/jboner/akka/blob/v1.2-RC2/akka-actor/src/main/scala/akka/dispatch/Future.scala#L723

So calls to apply and << inside a "flow"-block will be CPS transformed,
which in this case gives you code that looks imperative, but is actually
asynchronous and non-blocking.

Cheers,
√



> 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
> 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
>
> _______________________________________________
> 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/cdea45b5/attachment-0001.html>


More information about the Concurrency-interest mailing list