These are the slides related to my paper that I presented at the 2nd ICSE WUP. It gives a short background about the actor-model and describes what is my research project and its intended outcome.

1. Fábio Corrêa
Polelo Research Group
Computer Science Department
University of Pretoria

2.  The Free Lunch is Over
 Multi‐core Processors
 Software Crisis
 Industry and Academia are in a quest
in order to improve this situation
before dozen cores arrive and
slowdown the whole industry
 Millions of dollars are being
invested in research Sourc
e : Intel

3.  Ignored by most developers for years
 Difficult to master
 Threads, Locks, Race Condition, Deadlocks
and Shared/Mutable State
 Non‐Deterministic and Difficult to Debug
 Existing thread implementations
are somewhat low‐level
and not standardized
Source: AMD

4.  A HIGH‐LEVEL programming model
1. Easier to understand and master
2. Deterministic
3. Non‐shared/Non‐mutable state
4. Utilize all available cores without any re‐
configuration or re‐compilation
ntel
ce: I
Sour

5.  Actor Model of Concurrent Computation
 Formalism defined by Carl Hewitt et al. [MIT
AI Lab, 1973]
 Semantics solidified by Gul Agha [MIT AI Lab
(Message‐Passing Semantics Group), 1985]
 Research and implementations done along
the years
 Erlang is the flagship implementation

6.  REACTIVE entities that have a unique name
(mail address) and, based on an incoming
message received through its individual inbox
(message queue), can:
1. SEND a finite set of messages to other known
actors
2. CREATE a finite set of new actors
3. BEHAVE differently in relation to the next
incoming messages.

7.  ONLY through the exchange of messages
 Communication is ASYNCHRONOUS
 Non‐blocking SEND
 Blocking RECEIVE

8.  Messages are IMMUTABLE
 No synchronization devices (locks) required
 Not subject to memory corruption
 Actors are usually implemented on
lightweight processes (green threads)
 Messages are processed using pattern
matching

9.  In order to identify and model an actor
system, and its dynamics, the following must
be determined:
1. All type of actors of the system (classes?)
2. The contract that each actor responds to
(interfaces?)
3. The behavior that each actor should take when
receiving a message (methods?)

10.  An EMPIRICAL study that investigates the
viability of using the actor‐model as the
programming model for tackling the
concurrency crisis for business applications
 The audience is the developers community
 Software Engineering Trade‐Offs
 Effectiveness on multi‐cores
 Scalability
 Paradigm Change

11.  Design of a real‐life business application
 Develop a set of testing data
 Java implementation of the application
 Other implementations using:
1. Erlang + Actors + FP
2. Scala + Actors + OOP + FP
3. Java + Kilim + Actors + OOP
4. C# + CCR + Actors + OOP
5. F# + CCR + Actors + FP + OOP

12. A RATING ENGINE, a.k.a. rater, is an important

module of a billing system (BSS ‐ business
support system)
 A rater process input events and rate them
according to the price plan chosen by the
subscriber
 Typical users of a rater:
fixed‐line/wireless telephony providers

cable/satellite TV providers

water/electricity utility providers

banks


13. RATENG is a simplification of a rating engine for

a cellular carrier (wireless telephony provider)
 Events describe voice calls (in/out), text
messages (SMS) or data sessions (internet)
 Events were generated by subscribers (home or
roamers)
 Events were carried over the home network or in
another one
 As the outcome of each rated event, the balance
of the account and its related subscriptions must
be updated, according to the billing cycle when
the event occurred

14. FÁBIO CORRÊA
Mobile: 076‐816‐6848
eMail: feamcor@gmail.com

15.  No 3rd‐party tools will be used. All the
implementations somehow have to rely only
on the standard library of the tool that is
being used
 The Java implementation will be the baseline
for evaluating software engineering aspects
 The Erlang implementation will be the
baseline for evaluating scalability aspects

16. Erlang is a dynamically typed functional

language that was developed by Ericsson in 1985
and released as open‐source on 1997
 It was developed with soft real‐time,
concurrency, fault‐tolerance, distribution and
hot‐replacement in mind, due to the very nature
of the telephony environment
 The only concurrent programming model
available in Erlang is the actor‐model, being
today the de facto implementation and
reference for other implementations
 www.erlang.org

17. Hybrid programming language (FPL+OO)

created in 2003 at EPFL by Martin Odersky
 It implements the actor‐model as a library, based
on the Erlang implementation
 It compiles Java bytecodes and runs on top of a
JVM
 Java code can be used on Scala programs
without any problem
 Released as open‐source since its inception
 www.scala‐lang.org

18. Framework used to create robust and massively

concurrent actor systems in Java, which claims
to be, at least, 3x faster than Erlang
 It makes use of a bytecode post‐processor called
Weaver and a runtime library. Weaver ensures
that, through annotations on the bytecode:
1. Threads will be ultra‐lightweight;
2. Messages will be treated as a special, and much
simpler, category of Java objects; and
3. Isolation is enforced on compile‐time
www.malhar.net/sriram/kilim

19.  The Microsoft Concurrency and Coordination
Runtime and Decentralized Software Services
Toolkit comprises of “a set of .NET and .NET
Compact Framework class libraries and tools
that enable developers to better deal with the
inherent complexities in creating loosely‐
coupled concurrent and distributed
applications”
 CCR is the foundation of Maestro, a DSL for
concurrency developed by MS Research

20. The possible event scenarios, independently if the subscriber was in its

home network or in roaming (intra‐carrier or inter‐carrier), are:
Call to local fixed‐line number

Call to local wireless inter‐carrier number

Call to local wireless intra‐carrier number

Call to long‐distance fixed‐line number

Call to long‐distance wireless inter‐carrier number

Call to long‐distance wireless intra‐carrier number

Call to international fixed‐line number

Call to international wireless number

Incoming call

Text message to wireless inter‐carrier number

Text message to wireless intra‐carrier number

Text message to wireless international number

Incoming text message

Data session


21. The rating of an event will be driven by parameters like:

Minimum unit of charge for voice calls (6 seconds)

Minimum unit of charge for text messages (150 characters)

Minimum unit of charge for data sessions (1 kilobyte)

Off‐peak periods (by hour range on days of the week and holidays)

Rate, per off/peak minute, for calls while in home network

Rate, per off/peak minute, for calls while in intra‐carrier roaming

Rate, per text message, for messages while in home network

Rate, per text message, for messages while in intra‐carrier roaming

Rate, per off/peak KB, for data sessions while in home network

Rate, per off/peak KB, for data sessions while in intra‐carrier roaming

Bucket of off/peak free minutes per subscription/account

Bucket of free text messages per subscription/account

Bucket of off/peak free data volume per subscription/account

All events that occurred while in inter‐carrier roaming are rated by the visited

carrier and a toll is charged by the home carrier