actor-based programming for scalable concurrent systems

Actor-based Programming for Scalable Concurrent Systems Gul Agha

http://osl.cs.uiuc.edu

10/17/2008 Agha UPCRC Seminar 2

Outline

Defining the actor model High-level actor programming languages Implementing actors Orchestrating large numbers of actors


Motivation

Parallelism provides a natural decomposition of real-world application

Concurrent object-based programming languages can enable modularity in control as well as data.

Distributed programs can be transparently implemented on a variety of architectures Portability as the number of cores changes Seamless integration with sensor networks, cloud

computing


Challenges for Concurrent Programming Large-Scale Distribution

Multiple, interacting components Example: Multimedia applications How to manage interaction of components?

Lack of scalability of current concurrent programming techniques: User level thread management Shared memory with locks, unlocks


The Actor Model

ThreadState

Procedure

ThreadState

Procedure

ThreadState

Procedure

Interface

Interface

Interface

Messages


Actors as concurrent objects

A distributed system is a collection of actors

An actor is an autonomous, interacting component of a distributed system.

An actor has: an immutable identity

(name, virtual address) a mutable local state procedures to manipulate

local state a thread of control

Thread State

Procedure


The Actor Model: Fundamentals An actor may:

Process messages

send messages change local

state create new

actors

ThreadState

Procedure

ThreadState

Procedure

ThreadState

Procedure

Interface

Interface

Interface

Messages


Arrival Order Nondeterminism

Communication is asynchronous


Java’s Concurrency Model


Naming in Java and Actors

Java: Cannot uniquely refer to objects worldwide Restriction on migration

Actors: A mail address represents an actor’s locality in a virtual

computational space Use of a mail address independent of actor implementation

provides actors with location transparency


Programming in Actors

Coarse grained versus fine-grained Actors Advantage of fine-grained actors:

Can “over-decompose” application into actors As the number of cores increase, distribute the

actors Speed-up is constrained only by parallelism

in algorithm Retain parallelism inherent in the application


Programming Abstractions for Actors High-level language constructs capture

patterns of use Simplify expression of parallelism Facilitate optimizations through compiler and

runtime Support a separation of design concerns

Example of common high level language constructs Local synchronization constraints Call-reply communication


Local Synchronization Constraints

• Sender may not be in a state where it can process a message. Example: disable get( ) when empty (buffer)


Request Reply Communication


Join Continuation Transformation

Translation to basic actor semantics Can be automated

Avoids context-switching costs in implementations If the state of A depends on replies, transform to continuation

method


Concurrent Call/Return Communication in the Thal CompilerCreates join continuation closure (JCC): 4 components 1. counter number of empty slots 2. function invoked with JCC as argument 3. creator 4. argument slots Minimize switching cost using dataflow analysis

only necessary context is in JCC General transformation framework

identify set of mutually independent request expressions across statement boundary.


Two Approaches to Implementing Actors Programming Language

Pre-processor Compiler Interpreter

Libraries


Language Approach

Enforces actor semantics High-level abstractions for expressiveness Program transformations to achieve

efficiency Close interaction of compiler and run-time

system Examples: Rosette, THAL, SALSA, …


Actor Languages

Act1, Act2, Act3 (MIT): Lisp like syntax.. Rosette (MCC): scripting language Erlang: used for web services, telecom E-on-Lisp, E-on-Java: used for P2P systems SALSA (UIUC/RPI), THAL (UIUC): used in scientific

computing Ptolemy (UCB): used for real-time systems ActorNet (UIUC): sensor networks


Library Approach

ActorFoundry, AA: Java Libraries ActTalk: Smalltalk Act++, Broadway: C++ Kilim


ActorFoundry

Java Library supporting Actor Semantics Universal naming Single threaded objects Asynchronous communication Simplified migration Fair message delivery


Thal

A High-Level Actor Language Local synchronization constraints Request reply communication Actor groups (arrays, etc.) Programmer may control placement and migration of actors

Efficient compiler and runtime system All actors on a node share a single message queue Local messages transformed to function calls Join continuation transform to avoid context switches


Example Thal Program: Bank accountsbehv CheckingAccount

| curr_bal |init (ib, io) curr_bal = ib;endmethod deposit (id, teller) curr_bal = curr_bal + id; teller <- show_balance (curr_bal);endmethod withdraw (iw, teller) if (iw > curr_bal) then

teller <- overdrawn (iw – curr_bal); else

curr_bal = curr_bal - iw;teller <- done (iw);

endendmethod balance (teller) teller <- show_balance (curr_bal);end

end

Main| checking, atm,… |…checking = CheckingAccount.new(100);checking <- deposit (200, atm);checking <- withdraw (150, atm);

end


Owner computes semantics..

class Point { ... method compute () { myvalue = ((north.value()+ east.value() + west.value() + south.value())/4; self <- compute (); }} 5 point stencil Jacobi method with call/return

communication


Dynamic Actor Placement

Communication cost relatively independent of proximity of nodes, but... Sustained bandwidth may vary depending on

network traffic Optimal placement:

harmonizes locality and load balance is application architecture specific

THAL uses on <location> modifier for create


Thal Runtime Modules


Separation of Concerns

Would like to design and program at the level of interaction between applications

Want to specify and program different concerns separately

basic functionality security dependability / availability real-time requirements


Abstracting Interaction

How to express coordination modularly? Separate interaction policy from protocols used to

implement policy


Problems OS provides only low level communication and

resource management Different languages have different representations

and interaction mechanisms Coordination of distributed components is

complex Assuring non-interference -- concurrently

executing `independent’ services may share resources -- bandwidth, cycles, memory information -- database, sensors/actuators


Example: Auragen Primary Backup

Protocol Characteristics

1. independent of application

2. modifies communication

3. manipulates state


Components of a Protocol Instance

Roles define an actors behavior in the protocol


Transparent Implementation of ProtocolsReflection enables protocol implementations to be independent of

application implementations

A meta-level actor describes functionality of actor. To change the application’s behavior, modify the relevant meta-

actor: scheduler, communication system, memory


Example: Real Time Constraints


Applications

Customizable Protocols

Global SnapshotGlobal

Snapshot

Clock Synchronization

Clock Synchronization Contention

Resolution

Core Services

Actor 2 Actor 3

QoS Constraints

Periodic RT Constraint

Actor 1

ProtocolCustomization

Composable Core Services


Research Directions

New programming language abstractions Real-time constraints Any-time computations

Run-time for multi-core Maintain constraints Optimize power consumption


References

1. Gul Agha, “Concurrent object-oriented programming,” Communications of the ACM, Volume 33 Issue 9, September 1990.

2. WooYoung Kim and Gul Agha, “Efficient Support of Location Transparency in Concurrent Object-Oriented Programming Languages,” ACM Supercomputing, 1995.

3. Mark Astley, Daniel C. Sturman, and Gul Agha, “Customizable middleware for modular distributed software,” Communications of the ACM, Volume 44(5), pp 99-107, ACM 2001.

4. Carlos A. Varela, Gul Agha. "Programming Dynamically Reconfigurable Open Systems with SALSA," 16th Annual ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages, and Applications: Intriguing Technology Track, 2001, SIGPLAN Notices, vol. 36, pp20-34, ACM.

5. Nalini Venkatasubramanian, Carolyn L. Talcott, Gul Agha, “A Formal Model for Reasoning about Adaptive Qos-Enabled Middleware.” ACM Transactions Software Engineering Methodology, Volume 13(1), pp 86-147, ACM 2004.

6. Po-Hao Chang, Gul Agha, “Towards Context-Aware Web Applications,” Proceedings of the 7th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS 2007), Lecture Notes in Computer Science, volume 4531, pp 239-252, Springer, 2007.

actor-based programming for scalable concurrent systems

Documents