Your SlideShare is downloading. ×
Actors in a New "Highly Parallel" World
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Actors in a New "Highly Parallel" World

1,126
views

Published on

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.

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.

Published in: Technology

0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,126
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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