A visualisation and debugging tool for multi-active objects
Ludovic Henrio, Justine Rochas
LAMHA, Nov 2015
Agenda
I. Multi-active Objects: Principles
II. What is still difficult when
programming active objects
2
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
ba
result=beta.foo(b)
Request invocation
Caromel, D., Henrio, L.: A Theory of Distributed Object. Springer-Verlag (2005) 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
result=beta.foo(b)
foo
b
beta.foo(b)result
f
aRequest
invocation
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.getval()
foo
b
…..Result.getval()
f
aWait-by-necessity
WBN!!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
b
beta.foo(b)Result.getval()
f
a…
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
b
beta.foo(b)Result.getval()
a
f
A beta = newActive (“A”, …);V result = beta.foo(b);…..result.getval( );
Future sending
Result.getval()
7
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 join8
Compatibility =
requests can execute at the same time
and can be re-ordered
Declarative concurrency by annotating methods
Groups (Collection of related methods)
Rules (Compatibility relationships between groups)
Memberships(To which group each method belongs)
9
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 programMore parallelism More complex code / better
performance10
Agenda
I. Multi-active Objects: Principles
II. What is still difficult when
programming active objects
11
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
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’
Démo
14
15
• 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
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
Top Related