1. A visualisation and debugging tool for multi-active objects Ludovic Henrio, Justine Rochas LAMHA, Nov 2015

2. Agenda I.Multi-active Objects: Principles II.What is still difficult when programming active objects 2

3. ASP calculus / ProActive Java library Active objects are the unit of distribution and concurrency (one thread per AO / no data shared) Active and Passive objects Asynchronous method calls ; request queue With implicit transparent futures foo   result=beta.foo(b) Request invocation Caromel, D., Henrio, L.: A Theory of Distributed Object. Springer-Verlag (2005) 3

4. ASP calculus / ProActive Java library Active objects are the unit of distribution and concurrency (one thread per AO / no data shared) Active and Passive objects Asynchronous method calls ; request queue With implicit transparent futures result=beta.foo(b) foo  beta.foo(b) result f  Request invocation 4

5. ASP calculus / ProActive Java library Active objects are the unit of distribution and concurrency (one thread per AO / no data shared) Active and Passive objects Asynchronous method calls ; request queue With implicit transparent futures Result.getval() foo  ….. Result.getval() f  Wait-by- necessity WBN!! 5

6. ASP calculus / ProActive Java library Active objects are the unit of distribution and concurrency (one thread per AO / no data shared) Active and Passive objects Asynchronous method calls ; request queue With implicit transparent futures Result.getval() foo  beta.foo(b) Result.getval() f  … … 6

7. ASP calculus / ProActive Java library Active objects are the unit of distribution and concurrency (one thread per AO / no data shared) Active and Passive objects Asynchronous method calls ; request queue With implicit transparent futures Result.getval() foo  beta.foo(b) Result.getval()  f A beta = newActive (“A”, …); V result = beta.foo(b); ….. result.getval( ); Future sending Result.getval() 7

8. Multi-threading A programming model that mixes local parallelism and distribution with high-level programming constructs Execute several requests in parallel but in a controlled manner (compatibility notion) add() { … … } monitor() {… … } add() { … } Provided add, add and monitor are compatible join() Note: monitor is compatible with join 8

9. Declarative concurrency by annotating methods Groups (Collection of related methods) Rules (Compatibility relationships between groups) Memberships (To which group each method belongs) 9

10. Hypotheses and programming methodology We trust the programmer: annotations supposed correct static analysis or dynamic checks should be applied in the future Without annotations, a multi-active object has no race condition If more parallelism is required: 1. Add annotations for non-conflicting methods 2. Declare dynamic compatibility (depending on runtime values, eg request parameters) 3. Protect some memory access (e.g. by locks) and add new annotations Easy to program Difficult to program 10

11. Agenda I.Multi-active Objects: Principles II.What is still difficult when programming active objects 11

12. What is simpler with active objects Threads are isolated in an activity No data shared between activities Race conditions can only exist if compatibility is incorrect The only synchronisation is the access to a future Unique source of deadlock No need for locking or low-level synchronisation primitives (in general) 12

13. What is still difficult? Where can there be bugs? Deadlocks (e.g. re-entrant requests) Wrong compatibility annotations (out of scope here) Unplanned order of execution  ASP => order of execution depends on request reception order  Causal ordering of requests Too many threads (thread limit) or too few threads (blocked) 13 A C B 2 1 (e.g., init) 3 1 sent before 3 => 1 arrives before 3 A’

14. Démo 14

15. 15

16. Multi-active objects implemented on top of ProActive  A programming model for local concurrent and global distributed objects Many case studies & benchmarks  NAS, Content Addressable Network, GCM components, ProActive backend for ABS Visual post-mortem debugger of Multi-active Object app. Formal proofs (based on semantics)  « maximal parallelism »  Correctness of ABS translation Next steps:  Prove stronger properties, ongoing formalisation in Isabelle/HOL  Find deadlocks using behavioural types (ongoing PhD)  Design a recovery protocol for MAO Conclusion 16

17. Questions? Related publications: 1.Multi-threaded Active Objects. Ludovic Henrio, Fabrice Huet, and Zsolt István - In COORDINATION 2013. 2.Declarative Scheduling for Active Objects paper. Ludovic Henrio and Justine Rochas - SAC 2014. 3.Justine Rochas, Ludovic Henrio. A ProActive Backend for ABS: from Modelling to Deployment. Inria Research Report 2014. 17