Execution Support for Multithreaded Active Objects Design and

Execution Support for Multi-threaded Active Objects: Design and Implementation Justine Rochas Thesis supervised by Ludovic Henrio (CNRS) Reviewers Einar Broch Johnsen University of Oslo Lionel Seinturier Université de Lille Examiners Florian Kammüller Johan Montagnat Fabrice Huet Middlesex University London CNRS Université de Nice Sophia Antipolis 1

Motivation Example: airline reservation system Challenges ◦ Simultaneous accesses (concurrency) ◦ From anywhere (distribution) Other examples ◦ ◦ World wide web Massively multiplayer online games Banking systems Peer-to-peer travel data booking 2

How do I build that? The toolbox ◦ ◦ ◦ Programming models Programming languages Middlewares APIs Technologies 3

Global objectives Help the programmer in developing safe distributed and concurrent systems, easily Our approach ◦ Programming model (design) ◦ Middleware (implementation) Goals to keep in mind ◦ High level of abstraction ◦ Correct behaviour 4

Introduction Local scheduling Encoding Support Conclusion Outline 1. Introduction o Actors o Active objects o Multiactive objects 2. Local scheduling for multiactive objects 3. Encoding of cooperative active objects 4. Support for multiactive objects 5. Conclusion & perspectives 5

The actor programming model (1985) actor 6

Active objects (1996) Object-oriented programming model for concurrency Asynchronous method call (request) Placeholder for the result (future) S request queue request A RACE T A D O N SAFE… active object thread method call 7

The Pro. Active middleware Java library for distributed active objects Active + passive objects (activity) activity Bar bar = new. Active(Bar. class, parameters, node); Java syntax & transparent futures Foo foo = bar. compute(); Wait-by-necessity foo. use(); active object local reference passive object 8

Limitations of active objects Inefficient local parallelism ◦ Single-threaded data manipulation SAFE CT? I R T OS … TO Risk of deadlocks ◦ Circular dependency on future awaiting a b Deployment challenges ◦ ◦ Location transparency Exception handling Fault tolerance … 9

Related works: cooperative active objects Explicit release points in requests (await) ◦ Enable request interleaving ◦ Can avoid some deadlocks ◦ Require more skills ABS Balancer smsb = new Balancer("sms", 15); Fut<Int> f = smsb!send. Sms(); await f? ; Creol (2006) JCo. Box (2010) & ABS (2010) ◦ Sets of active objects sharing one active thread smsb two sets of active objects 10

Related works: Scala (2006) / Akka (2010) Single-threaded actors Still deadlock-prone (futures) Practical aspects fully addressed Low-level configuration mixed with the business logic Akka class Master extends Actor { def receive = { case Calculate ⇒ println("Received") context. system. shutdown() } } def calculate(nb. Workers: Int) { val system = Actor. System("Pi. System") val master = system. actor. Of(Props[Master], name="m") val future = master ? Calculate val result = Await. result(future, 3 seconds) . as. Instance. Of[String] } 11

Multiactive objects (2013) Goal ◦ Local request parallelism (thread-based) Challenge ◦ Avoid data races between requests multiple threads Principle ◦ Declare compatibility of requests SAFE –> C RO ONT LLED 12

Multiactive objects in Pro. Active Class annotations Parallelisable requests ◦ add – log ◦ log – log Not parallelisable ◦ add – add @Define. Groups({ @Group(name="routing", self. Compatible=false), @Group(name="monitoring", self. Compatible=true) }) @Define. Rules({ @Compatible({"routing", "monitoring"}) }) class Peer { @Member. Of("routing") void add(Key k, Data d) { … } @Member. Of("monitoring") void log(String m) { … } } 13

Results of thesis Contributions to the multiactive object framework ◦ Enhanced local parallelism ◦ Execution support at the middleware level Contribution to the active object community ◦ Encoding of cooperative active objects Implementation and formal aspects of active object languages 14

Introduction Local scheduling Encoding Support Conclusion Outline 1. Introduction 2. Local scheduling for multiactive objects o o o Default scheduling Thread limit Priority 3. Encoding of cooperative active objects 4. Support for multiactive objects 5. Conclusion 15

Default scheduling of multiactive objects Maximisation of request parallelism Execute when compatible with ◦ Executing requests ◦ Or ahead in the queue Too many threads can be created 16

Controlling threads of multiactive objects Limit number ◦ Global thread limit ◦ Per multiactive object Limit type @Define. Thread. Config(thread. Pool. Size=2, hard. Limit=false) class Peer { … } ◦ Hard thread limit (all threads) ◦ Soft thread limit (active threads) Can be changed programmatically threads in wait-by-necessity 17

Controlling threads of request groups … @Group(name="routing", self. Compatible=false, min. Threads=2, max. Threads=5), … @Define. Thread. Config(thread. Pool. Size=8, hard. Limit=true) class Peer { … } Threads never used by the routing group max min The programmer never manipulates threads directly 18

Contention in multiactive object queue compatible thread limit = 3 ready queue a Request priority! [2] Declarative Scheduling for Active Objects, SAC 2014 19

Priority specification mechanism … @Define. Priorities({ @Priority. Hierarchy({ @Priority. Set(group. Names={"G 1"}), @Priority. Set(group. Names={"G 2"}), @Priority. Set(group. Names={"G 4", "G 5"}) @Priority. Hierarchy({ @Priority. Set(group. Names={"G 3"}), @Priority. Set(group. Names={"G 4"}) }) }) … class Peer { … } high priority G 1 G 3 G 2 G 4 G 5 low priority graph of request groups 20

Insertion time of requests with priority Insertion time (ms) transitive graph Same performance as integers, but more expressive Number of requests in the queue 21

Related works in active object scheduling Programmatic schedulers: ABS (2010), Parallel Actor Monitor (2014) ◦ Permissive Application-level scheduling: Pro. Active, Creol (2006) ◦ Safer ◦ Different priority locations 22

Safe Local scheduling for multiactive objects Expressive Easy to reason about Efficent Linked to request groups Conclusion A balanced approach 23

Introduction Local scheduling Encoding Support Conclusion Outline 1. Introduction 2. Local scheduling for multiactive objects 3. Encoding of cooperative active objects o o o ABS Pro. Active backend Fomalisation 4. Support for multiactive objects 5. Conclusion 24

Motivation & results Translation of ABS programs into Pro. Active programs General comparison of active object languages DIST DEPLOYM RIBU TED ENT, EXEC UTIO N NG, I L L DE N MO ICATIO IF VER ABS source code Pro. Active backend Pro. Active generated code 25

The ABS language Active object modelling language ◦ Concurrent Object Groups (COG) ◦ Explicit syntax (! and Fut<T>) ◦ Cooperative scheduling (await) Toolset ◦ Verification & program analysis ◦ Execution through backends (Erlang, Haskell, Java…) A a = new local A(); B b = new B(obj, …); b!foo(a); COG a o COG foo(A a) { Fut<V> v. Fut = a!bar(); await v. Fut? ; V v = v. Fut. get; v. do. Smt(); } x y b 26

Challenges of the translation ABS Pro. Active active object model object groups active & passive objects asynchronous calls local distributed request scheduling cooperative multi-threaded 27

Challenges of the translation active object model ABS Pro. Active object groups active & passive objects COG 1 COG = 1 active object registry COG asynchronous calls local distributed request scheduling cooperative multi-threaded 28

Translation of a new statement ABS Pro. Active Server server = new Server() (1) Create Java Object (2) Create Pro. Active active object (3) Make Java object available to Pro. Active active object Server server = new Server() COG cog = new. Active(COG. class, {}, node 2) (2) cog. register. Object(server) (3) (1) node 2 node 1 server cog (proxy) server (copy) cog registry 29

Challenges of the translation active object model asynchronous calls ABS Pro. Active object groups active & passive objects local distributed COG Two-level addressing system request scheduling COG cooperative multi-threaded 30

Translation of an asynchronous call ABS Pro. Active server!start() server. get. Cog(). execute("start", {}, server. get. ID()) LE HAB PAS SI BJ O E V ECT CO S BE C REA E M node 1 node 2 server (copy) get. Cog cog (proxy) execute start execute cog registry ID ref 31

Challenges of the translation ABS Pro. Active active object model object groups active & passive objects asynchronous calls local distributed cooperative multi-threaded request scheduling COG Soft thread limit 32

Translation of an await statement ABS await f? (1) Make execute requests compatible (2) Limit the COG to 1 active thread Simulates the execution transfer of ABS Pro. Active PAFuture. get. Future. Value(f) @Define. Groups({ @Group(name="scheduling", self. Compatible=true) }) @Define. Thread. Config(thread. Pool. Size=1, hard. Limit=false) public class COG { @Member. Of("scheduling") public ABSType execute(…) { … } } 33

Formalisation: translation correctness [4] DISTRIBUTED ASPECTS programming model Multiactive Objects Pro. Active implementation Multi. ASP ABS Async. call Multi. ASP formalisation Async. call Theorem 1 from ABS to Multi. ASP Theorem 2 from Multi. ASP to ABS ≈ Sync. call Return sync. silent actions Assignment [4] From Modelling to Systematic Deployment of Distributed Active Objects, Coordination 2016 34

On representation of futures… Control flow (ABS) vs data flow (Multi. ASP/Pro. Active) ◦ No straight simulation, future indirection must be followed in the proof { A a = new A(); class A { future f 1 future f 2 Fut<Int>> f 1 = a!foo(); in ABS… ≠ Fut<Int> foo() { empty B b = new B(); Fut<Int> f 2 = b!bar(); return f 2; } Fut<Int> f 2 = f 1. get; Int i = f 1. get; return 0; return i; } class B { � ✓ } Int bar() { future f 1 while True { empty } } Only the progams with half-computed } futures behave differently EQUIVALENCE LOST HERE 35

Restrictions of the translation The value of a future cannot be a future (from ABS to Multi. ASP) FIFO service / Causal ordering of requests (both directions) Distribution of future updates (from Multi. ASP to ABS) node 2 node 1 f v v Restrictions due to distributed execution await f? f node 3 v f node 4 v await f? f 36

Systematic deployment of cooperative active objects Cooperative active objects –> multiactive objects ◦ Faithful translation Practical result ◦ Implemented backend Formal result ◦ Proof of correctness of the simulation Conclusion Restrictions were defined thanks to formalisation 37

Introduction Local scheduling Encoding Support Conclusion Outline 1. Introduction 2. Local scheduling for multiactive objects 3. Encoding of cooperative active objects 4. Support for multiactive objects o o Debugging Fault tolerance 5. Conclusion 38

Development and execution support For multiactive objects Help in finding bugs NG GGI U B E D Help with unstable distributed environments NCE A R LE O LT T FAU 39

Debugger for multiactive objects Peer 2 Peer 4 Peer 1 Peer 3 40

Debugging: concurrent read & writes WRITE READ WRITE 41

Debugging: deadlock s 42

Fault tolerance 43

Recover upon faults request Pro. Active active object 44

Checkpoint multiactive objects… thread 1 thread 2 Pro. Active multiactive object thread 3 thread 4 TE STA H HIC ED SAV ? ? W 45

Checkpoint with multiactive scheduling n n+1 checkpoint thread limit = 1 Checkpoint as-a-request, thread limit, and priority request checkpoint thread limit = 3 request, n+1 46

Request and communication debugger ◦ Several users Support for multiactive objects Adapted fault tolerance protocol ◦ Extracted from the middleware as multiactive object annotations conclusion Implementation of non-functional aspects thanks to multiactive object scheduling 47

Introduction Local scheduling Encoding Support Conclusion Outline 1. Introduction 2. Local scheduling for multiactive objects 3. Encoding of cooperative active objects 4. Support for multiactive objects 5. Conclusion o o Summary Perspectives 48

Recap(plication): peer-to-peer d d? 49

Recap(plication): peer-to-peer a @Define. Groups({ @Group(name="data. Management", self. Compatible=false), @Group(name="monitoring", self. Compatible=true), … }) @Define. Rules({ @Compatible({"data. Management", "monitoring"}), … }) @Define. Priorities({ @Priority. Hierarchy({ @Priority. Set({"data. Management"}), @Priority. Set({"monitoring"}), … }) }) @Define. Thread. Config(thread. Pool. Size=2, hard. Limit=false); public class Peer { … } ü Multiactive object annotations ü Improved local scheduling ü Thread limit & priority 50

Recap(plication): peer-to-peer Efficient & robust implementation of peer-to-peer system INIT [1] An Optimal Broadcast Algorithm for Content-Addressable Networks, OPODIS 2013 51

Recap(plication): translation multiactive object COG Equivalent behaviour –> preservation of guarantees ü Translation of cooperative scheduling ü Proof of correctness ü Efficient Pro. Active backend for ABS 52

Conclusion multiactive object framework C AC R A H ICS T S I TER Compatibility IC NS O I AT L APP Peer-to-peer Multi-threading Fault tolerance Priority Thread limit Pro. Active backend for ABS 53

Perspectives The multiactive object framework ◦ Mature fault tolerance ◦ Dynamic priorities Multiactive objects analysis ◦ Deadlock detection in Multi. ASP programs (on-going Ph. D) ◦ Specification and verification of multiactive components ◦ Static analysis of annotations @Define. Groups({ @Group(name="routing", …), @Group(name="monitoring", …) }) @Define. Rules({ @Compatible({"routing", "monitoring"}) }) class Peer { @Member. Of("routing") void add(Key k, Data d) { … } @Member. Of("monitoring") void log(String m) { … } } Statically check absence of concurrent accesses 54

Publications [1] Ludovic Henrio, Fabrice Huet and Justine Rochas. “An Optimal Broadcast Algorithm for Content. Addressable Networks’’. In: Proceedings of the 17 th International Conference on Principles of Distributed Systems. OPODIS 2013. [2] Ludovic Henrio and Justine Rochas. “Declarative Scheduling for Active Objects”. In: Proceedings of the 29 th Annual ACM Symposium on Applied Computing. SAC 2014. [3] Ge Song, Justine Rochas, Fabrice Huet and Frédéric Magoulès. “Solutions for Processing K Nearest Neighbor Joins for Massive Data on Map. Reduce”. In: 23 rd Euromicro International Conference on Parallel, Distributed and Network-based Processing. PDP 2015. [4] Ludovic Henrio and Justine Rochas. “From Modelling to Systematic Deployment of Distributed Active Objects”. In: 18 th International Conference, COORDINATION 2016, Held as Part of the 11 th International Federated Conference on Distributed Computing Techniques. Dis. Co. Tec 2016. Selected for special issue of Logical Methods in Computer Science journal. [5] Ge Song, Justine Rochas, Léa El Beze, Fabrice Huet and Frédéric Magoulès. “K Nearest Neighbour Joins for Big Data on Map. Reduce: a Theoretical and Experimental Analysis”. In: IEEE Transactions on Knowledge and Data Engineering. 2016. Execution Support for Multi-threaded Active Objects: Design and Implementation – Justine Rochas 55