1 Joint work with Claudio Antares Mezzina (INRIA), Jean-Bernard Stefani (INRIA) and Alan Schmitt (INRIA) Controlling Reversibility in Rhopi Ivan Lanese Computer Science Department Focus research group University of Bologna/INRIA Bologna, Italy

Roadmap l Our aim l Reversibility l A rollback operator l Conclusions

Roadmap l Our aim l Reversibility l A rollback operator l Conclusions

Do you remember Rhopi? l What I will present is a follow-up of Rhopi’s talk, presented by Claudio Mezzina at last seminar l I will briefly recall it, but mainly build on top of it

What Rhopi really is? l Rhopi, as well as the calculi RCCS and CCSk, propose (slightly different) answers to the same question:

A tool l For us, Rhopi is a tool l We want to reverse processes to program dependable distributed systems –The same tool can be used also for different purposes (e.g., modelling biological systems) l Rhopi alone is not enough –We want to go back only in case of errors –We want to specify how far back to go –We want to avoid repeating the same errors –We want to make the good results permanent –We want to add compensations to the mix

Drawbacks of Rhopi alone

l Absolutely no control l Impossible to make a result permanent –The activity producing it can always be undone –No commit –All the states are (weak) equivalent l Each program is either stuck or divergent

The small-step approach l Add simple mechanisms for controlling reversibility –In RCCS: irreversible actions –Here: a rollback primitive –Other interesting possibilities exist l Understand their behavior –In a concurrent setting –Expressive power

Final destination l Can reversibility act as an underlying theory for understanding various techniques for dependability in distributed systems? –Checkpointing –Transactions –Apple Time Machine –…–…

Roll-pi idea l Normal computation goes forward l There is an explicit primitive, roll γ, to trigger a rollback l γ refers to a specific point in the past of the program –In a concurrent world, difficult to speak about time –We refer to an action to undo »Includes undoing all the actions depending on it l … and now we need some formal stuff

Roadmap l Our aim l Reversibility l A rollback operator l Conclusions

HOpi fundamentals

Rhopi syntax

Rhopi semantics l A forward rule similar to HOpi, managing tags and creating a memory l A backward rule for going back F orward : m = ( · 1 :a h P i ) j ( · 2 :a ( X ). Q ) ( · 1 :a h P i ) j ( · 2 :a ( X ). Q ) ³ º k : ( k : Q f P = X g ) j [ m; k ] B ackward : ( k : P ) j [ m; k ] Ã m

Rhopi example k 3 : b ( X ). c h 0 ij X k 1 :a h P i k 2 :a ( X ). b h d h 0 ii

k 3 : b ( X ). c h 0 ij X [ k 1 : M j k 2 : N ; k ] k : b h d h 0 ii k 1 :a h P i k 2 :a ( X ). b h d h 0 ii

k 3 : b ( X ). c h 0 ij X [ k 1 : M j k 2 : N ; k ] k : b h d h 0 ii [ k : b h d h 0 iij k 3 : N 1 ; k 4 ] k 4 : ( c h 0 ij d h 0 i ) k 1 :a h P i k 2 :a ( X ). b h d h 0 ii

k 3 : b ( X ). c h 0 ij X [ k 1 : M j k 2 : N ; k ] k : b h d h 0 ii k 1 :a h P i k 2 :a ( X ). b h d h 0 ii

k 3 : b ( X ). c h 0 ij X k 1 :a h P i k 2 :a ( X ). b h d h 0 ii

Roadmap l Our aim l Reversibility l A rollback operator l Conclusions

Roll pi syntax l Extends Rhopi syntax l Adds the primitive roll γ for triggering rollback l Adds a γ label to triggers l The idea: roll γ takes the system back to the state before the trigger labelled by γ has been consumed l More precisely: undoes all the steps caused by the interaction involving the trigger labelled by γ P ; Q :: = 0 j X j ºa : P j ( P j Q ) j a h P ij a ( X ). ° P j ro ll ° M ; N :: = 0 j ºu : M j ( M j N ) j ·: P j [ ¹; k ]

Giving semantics: naïve try l The forward rule uses the key k to replace the placeholder γ l A rule for roll l N ►k verifies that all the elements in N are related to k l Complete checks that the term is closed under causal relation l contains the elements in N not related to k N & k

Naïve semantics example k 3 : b ( X ). c h 0 ij X k 1 :a h 0 i k 2 :a ( X ). ° b h ro ll ° i

k 3 : b ( X ). c h 0 ij X [ k 1 : M j k 2 : N ; k ] k 1 :a h 0 i k : b h ro ll k i k 2 :a ( X ). ° b h ro ll ° i

k 3 : b ( X ). c h 0 ij X [ k 1 : M j k 2 : N ; k ] k 1 :a h 0 i k : b h ro ll k i [ k : M 1 j k 3 : N 1 ; k 4 ] h h 1 ; ~ h i ¢ k 4 :c h 0 ih h 2 ; ~ h i ¢ k 4 : ro ll k k 2 :a ( X ). ° b h ro ll ° i

k 3 : b ( X ). c h 0 ij X [ k 1 : M j k 2 : N ; k ] k 1 :a h 0 i k : b h ro ll k i [ k : M 1 j k 3 : N 1 ; k 4 ] h h 1 ; ~ h i ¢ k 4 :c h 0 ih h 2 ; ~ h i ¢ k 4 : ro ll k k 2 :a ( X ). ° b h ro ll ° i

k 3 : b ( X ). c h 0 ij X k 1 :a h 0 i k 2 :a ( X ). ° b h ro ll ° i

The concurrency anomaly kk 1 ro llk ro llk 1

kk 1 ro llk ro llk 1

k 1

kk 1 ro llk ro llk 1

k

l Intuitively, I have rolls for undoing every action… l …but I am not able to go back to the starting state l I miss the possibility of performing rollbacks concurrently l Can I write a semantics capturing this aspect?

Giving semantics: taming concurrency l The rollback has been splitted in two steps –Tagging the memory –Executing the rollback of a tagged memory

Concurrent rollback kk 1 ro llk ro llk 1

kk 1 ro llk ro llk 1

kk 1 ro llk ro llk 1

k 1

Properties of concurrent semantics l Correct –If I go backward from M, I reach a state able to go forward to M l Complete –I can simulate any number of concurrent rollbacks l Good as abstract specification i f M Ã ¤ M 0 t h en M 0 ³ ¤ M, w i t h M an d M 0 unmar k e d

Going towards an implementation l The concurrent semantics is very high-level l Includes atomic steps involving an unbounded number of participants –Concurrently executing –Possibly distributed l Can we refine the semantics to a more distributed one? –Giving the same final result l Yes! l But technicalities are quite complex…

Low level semantics k ro llk

k ro llk

k ro llk

k ro llk

k

l Based on local checks and asynchronous notifications l In two phases –Top-down notification of rollback request –Bottom-up rollback l Equivalent to the concurrent one –Weak bisimilar –Fully abstract l Writing a low level semantics equivalent to the naïve one would be more difficult l A good starting point for a concurrent and distributed implementation

Roadmap l Our aim l Reversibility l A rollback operator l Conclusions

Summary l A basic operator for controlling reversibility in Rhopi –Related to checkpointing l A semantics suitable for concurrent settings l A low level semantics going towards implementation

Future work l A long road in front of us l Which other mechanisms for controlling reversibility can one define? l Which is the relation with well-established techniques for dependable systems? l Can we introduce in a smooth way long running transactions and compensations? l Which is the relation with modularity?

Rhopi for searching l No difference between backward and forward l Every time a process acts, a counter related to it is incremented l I choose to execute processes with lower value of the counter l Outcome: I explore new interactions as far as possible

Finally