+ All Categories
Page 1: Reversibility in Concurrency


Joint work with Michael Lienhardt (PPS), Claudio Antares Mezzina (Trento), Jean-Bernard Stefani (INRIA) and

Alan Schmitt (INRIA)

Reversibility in Concurrency

Ivan LaneseComputer Science Department

Focus research groupUniversity of Bologna/INRIA

Bologna, Italy

Page 2: Reversibility in Concurrency


Reversibility Uncontrolled reversibility Controlled reversibility Compensations Conclusions

Page 3: Reversibility in Concurrency

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

In some areas systems are naturally reversible: biology, quantum computing, …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

Page 4: Reversibility in Concurrency

In concurrent systems one cannot simply undo “the last action”– It is not clear which is the last action

Independent threads are reversed independently Causal dependencies should be respected

– First reverse the consequences, then the causes

Concurrent reversibility





Page 5: Reversibility in Concurrency

In concurrent systems one cannot simply undo “the last action”– It is not clear which is the last action

Independent threads are reversed independently Causal dependencies should be respected

– First reverse the consequences, then the causes

Causal Consistent Reversibility





Page 6: Reversibility in Concurrency

Research questions

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

new ones?

Page 7: Reversibility in Concurrency

How do I reverse a concurrent computation?

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]

These works define the semantics of uncontrolled reversibility

– No hint on when to go backward and up to where Useful to understand the possible behaviors More useful as models than as programming languages

Page 8: Reversibility in Concurrency

Main idea

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

Page 9: Reversibility in Concurrency

Power is nothing without control

Programs based on uncontrolled reversibility are not very useful

– They always diverge– No way to make a result persistent

We want to go back only when needed– In particular, in case of errors

We want to specify how far back to go

Page 10: Reversibility in Concurrency

Reversibility control

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]

Page 11: Reversibility in Concurrency

Roll-π idea

Normal computation goes forward There is an explicit primitive, roll γ, to trigger a rollback γ 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


Page 12: Reversibility in Concurrency

Is roll-π enough?

Roll-π allows to control reversibility– Backtracking only in case of need– Otherwise the computation proceeds forward

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

Each roll-π program is divergent We want to remember the past tries and learn from them

Page 13: Reversibility in Concurrency


From database theory and business processes– Piece of code to recover from an error– Moving from the error state to a safe state

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

Page 14: Reversibility in Concurrency

Actions with compensations

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

If the action with compensation is the target of the rollback, it is replaced by its compensation

Using compensations the programmer may now avoid looping

Page 15: Reversibility in Concurrency

The croll-π calculus [ESOP 2013]

A causal consistent reversible higher-order π With a rollback operator And with compensations attached to messages

– Only messages allowed as compensations No other reversible calculi with compensations in the


Page 16: Reversibility in Concurrency

And now?

We have to test the expressive power of messages with compensations

Can we programme interesting applications exploiting rollback and compensations?

Can we recover/improve recoverability patterns from the literature?

And invent new ones?

Page 17: Reversibility in Concurrency

Messages with compensations are robust

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

Page 18: Reversibility in Concurrency

What can we model?

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 Can we recover/improve existing techniques?

– Software transactional memory model from Acciai et al. [ESOP’07]

– Interacting transactions from Hennessy et al. [CONCUR 2010]

Page 19: Reversibility in Concurrency

Interacting transactions

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

Interacting transactions are allowed to interact with the environment during their execution

Page 20: Reversibility in Concurrency

Hennessy interacting transactions

Page 21: Reversibility in Concurrency

Our approach

A transaction is started by an action with compensation Undo is modelled by rollback Effects of the transaction are automatically undone A compensation can be specified Our causality tracking is more precise than Hennessy

embedding mechanism We avoid some spurious rollbacks they have

Page 22: Reversibility in Concurrency


Causal consistent reversible calculi Mechanisms for controlling reversibility

– Roll operator Compensations for programming what to do after

rollback Some interesting applications

Page 23: Reversibility in Concurrency

Future work

A long road in front of us Which other mechanisms for controlling reversibility

can one define? Can we recover/improve/combine other techniques for

dependable systems from the literature? Studying the behavioral theory of reversible calculi Going towards more complex languages

– Klaim, Concurrent ML, Erlang What about a reversible debugger?

Page 24: Reversibility in Concurrency


Top Related