Home

Actors that Unify Threads and Events

In this paper we present an abstraction of actors that combines the benefits of thread-based and event-based concurrency. Threads support blocking operations such as system I/O, and can be executed on multiple processor cores in parallel. Event-based computation, on the other hand, is more lightweight and scales to large numbers of actors. We also present a set of combinators that allows a flexible composition of these actors.

Philipp Haller and Martin Odersky also wrote Event-Based Programming without Inversion of Control which was discusssed here last year. You may also remember A Language-based Approach to Unifying Events and Threads (Li and Zdancewic).

By James Hague at 2007-02-22 23:39 | Parallel/Distributed | other blogs | 12789 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

distributed processes?

In Erlang, apparently distributing processes across machines is not much more work than keeping the whole system on a single machine, is that true of Scala as well?

Are there any plans to provide behaviors such as gen_fsm or gen_server?

By shahbaz at Fri, 2007-02-23 05:58 | login or register to post comments

Distribution of Scala actors

Distribution of Scala actors is similar to Erlang. An actor is made remotely accessible by declaring that it is alive (for TCP: on some port), and registering a name for it. After that, it can be accessed by selecting its name from the remote node. Since the user's manual is not yet available, I point you to the Scala API documentation which contains an example in the ScalaDoc for RemoteActor in package scala.actors.remote.

David Pollak is also working on integrating JXTA as transport layer. In the process of this effort we might also consider redesigning and extending support for remote actors. So far, our focus has been on (local) concurrency for multi-core machines.

By hallerp at Fri, 2007-02-23 23:10 | login or register to post comments

gen_fsm, gen_server

I am not (yet) familiar with gen_fsm and gen_server. However, if people provide us with convincing use cases on the Scala mailing list, we might come up with something. ;-)

By hallerp at Fri, 2007-02-23 23:19 | login or register to post comments

link

You may also remember A Language-based Approach to Unifying Events and Threads (Li and Zdancewic)

(...which was discussed on LtU here.)

By Dave Herman at Fri, 2007-02-23 15:48 | login or register to post comments

Control Inversion

Actually the whole Felix programming language is based on using a high level tool to translate thread oriented code (Felix) into lower level event driven code (C++). The programmer can spawn both pre-emptive and non-premptive threads. Communication is either via shared memory or using channels.

The library automatically lifts pthread blocking calls such as socket operations so that they only block a fibre (by translating the operation to use asynchronous I/O with OS best event notification). So you can happily block fibres as if they were real threads, but other fibres of the same pthread do not get blocked.

By skaller at Tue, 2007-02-27 09:35 | login or register to post comments