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

Roadmap l Reversibility l Uncontrolled reversibility l Controlled reversibility l Compensations l Conclusions

What is reversibility? The possibility of executing a (concurrent) computation both in the standard, forward direction, and in the backward direction, going back to a past state l In some areas systems are naturally reversible: biology, quantum computing, … l In concurrent systems reversibility allows for recoverability –In case of error I go back to a past state which is safe –We want to use reversibility as a general framework for programming reliable applications

l In concurrent systems one cannot simply undo “the last action” –It is not clear which is the last action l Independent threads are reversed independently l Causal dependencies should be respected –First reverse the consequences, then the causes Concurrent reversibility a a b b

l In concurrent systems one cannot simply undo “the last action” –It is not clear which is the last action l Independent threads are reversed independently l Causal dependencies should be respected –First reverse the consequences, then the causes Causal Consistent Reversibility a a b b

Research questions l How do I reverse a concurrent computation? l How do I control reversibility? l How do I avoid redoing the same errors? l Can I recover existing dependability patterns and devise new ones?

How do I reverse a concurrent computation? l A few approaches in the literature –RCCS by Danos and Krivine [CONCUR 2004] –CCSk by Phillips and Ulidovski [FoSSaCS 2006] –Rhopi by Lanese et al. [CONCUR 2010] –Reversible structures by Laneve and Cardelli [CMSB 2011] –Reversible µOz by Lanese et al. [FMOODS/FORTE 2012] l These works define the semantics of uncontrolled reversibility –No hint on when to go backward and up to where l Useful to understand the possible behaviors l More useful as models than as programming languages

Main idea l I keep track of past communication actions and of causal dependencies –Communication should cause no loss of information –Substitutions normally causes loss of information –Different technical solutions

Power is nothing without control l Programs based on uncontrolled reversibility are not very useful –They always diverge –No way to make a result persistent l We want to go back only when needed –In particular, in case of errors l We want to specify how far back to go

Reversibility control l Different approaches in the literature –Irreversible actions by Danos and Krivine [CONCUR 2005] –Rollback operator by Lanese et al [CONCUR 2011] –Energy parameters by Bacci et al [CALCO 2011] –Monitors by Phillips et al [RC 2012]

Roll-π idea l Normal computation goes forward l There is an explicit primitive, roll γ, to trigger a rollback l γ refers to a specific action done in the past –We specify which action to undo –As a result we undo all the actions depending on it –Independent actions are not undone –In a concurrent world one cannot say “undo the last 10 actions”

Is roll-π enough? l Roll-π allows to control reversibility –Backtracking only in case of need –Otherwise the computation proceeds forward l In case of rollback –We go back to a past consistent state –And we execute forward again from it –We may take the same path, obtaining the same error again –Good for transient errors, not for permanent ones l Each roll-π program is divergent l We want to remember the past tries and learn from them

Compensations l From database theory and business processes –Piece of code to recover from an error –Moving from the error state to a safe state l For us, piece of code allowing to move –From the past consistent state produced by the rollback –To a slightly different state –Keeping into account the past try –Trying to avoid to repeat the same error

Actions with compensations l Instead of actions A we use actions with compensations –A%0 : try A then stop trying –A%B%0 : try A then B then stop trying l If the action with compensation is the target of the rollback, it is replaced by its compensation l Using compensations the programmer may now avoid looping

The croll-π calculus [ESOP 2013] l A causal consistent reversible higher-order π l With a rollback operator l And with compensations attached to messages –Only messages allowed as compensations l No other reversible calculi with compensations in the literature

And now? l We have to test the expressive power of messages with compensations l Can we programme interesting applications exploiting rollback and compensations? l Can we recover/improve recoverability patterns from the literature? l And invent new ones?

Messages with compensations are robust l We can encode different idioms: –General compensations: not only messages –Finite retry: try n times –Endless retry: try forever (same as roll-π) –Triggers with compensations: we attach compensations to triggers instead of to messages

What can we model? l Interesting problems, programmed on top of a Maude interpreter –State space exploration with backtracking: 8 queens problem –Error handling scenario: Automotive case study from Sensoria project l Can we recover/improve existing techniques? –Software transactional memory model from Acciai et al. [ESOP’07] –Interacting transactions from Hennessy et al. [CONCUR 2010]

Interacting transactions l A transaction is a computation that may –Succeed, making the results permanent –Abort, undoing all its effects –May have a compensation to be executed upon abort l Interacting transactions are allowed to interact with the environment during their execution

Hennessy interacting transactions

Our approach l A transaction is started by an action with compensation l Undo is modelled by rollback l Effects of the transaction are automatically undone l A compensation can be specified l Our causality tracking is more precise than Hennessy embedding mechanism l We avoid some spurious rollbacks they have

Summary l Causal consistent reversible calculi l Mechanisms for controlling reversibility –Roll operator l Compensations for programming what to do after rollback l Some interesting applications

Future work l A long road in front of us l Which other mechanisms for controlling reversibility can one define? l Can we recover/improve/combine other techniques for dependable systems from the literature? l Studying the behavioral theory of reversible calculi l Going towards more complex languages –Klaim, Concurrent ML, Erlang l What about a reversible debugger?

Finally