1

Joint work with Claudio Antares Mezzina and Jean-Bernard Stefani

Controlled Reversibility and Compensations

Ivan LaneseFocus research group

Computer Science DepartmentUniversity of Bologna/INRIA

Italy

Roadmap

Reversibility and

concurrency

Controlling reversibility

Compensations

Conclusions

Roadmap

Reversibility and

concurrency

Controlling reversibility

Compensations

Conclusions

Why we are interested in reversibility?

We want programming abstractions for dependable distributed systems

Different proposals in the literature– Exception handling, checkpointing, transactions, …

Unrelated proposals, difficult to combine and compose Is there a unifying concept?

… most of them include some form of undo

What if we could undo every action?

Very low-level mechanism Can we build suitable abstractions on top of it? Can we recover and better understand traditional error

recovery schemes? Can we find new schemes or combine old ones?

Reversing concurrent systems

What does it mean to go back one step for a concurrent system?

First approach in

Reversible Communicating Systems. CONCUR 2004

by V. Danos and J. Krivine

Reversible Communicating Systems

Presents the RCCS calculus – A reversible version of CCS

Causal consistent reversibility– Transitions should be rollbacked in any order compatible

with causal dependencies

Causal consistent reversibility

a

a

b

b

Many reversible calculi

Reversible variants of many calculi have been studied– CCS-like calculi: Phillips & Ulidowski [FoSSaCS 2006,

JLAP 2007]

– HOπ: Lanese, Mezzina & Stefani [CONCUR 2010]

– μOz: Lienhardt, Lanese, Mezzina & Stefani [FMOODS&FORTE 2012]

All causally consistent All allowing to reverse each single step All providing perfect reversibility

End of the story?

These calculi specify how to reverse computations, but not when

If programs choose nondeterministically whether to go back or to go forward we get useless programs

– Always diverge

– If I get a result I cannot make it persistent

Roadmap

Reversibility and

concurrency

Controlling reversibility

Compensations

Conclusions

Controlling reversibility

We want techniques to decide when to go back and when to go forward

– Avoiding the drawbacks described before

The technique depends on the aim of reversibility For error recovery

– Normal computation is forward

– In case of error, go back to reach a consistent state» Requires to undo many steps at the time

Go back n steps is not meaningful– In a concurrent setting it is not clear which the last steps are

Who should control reversibility?

Different possibilities We propose a taxonomy

– Internal control: reversibility is controlled by the programmer

– External control: reversibility is controlled by the environment

– Semantic control: reversibility control is embedded in the semantics of the language

Internal control

Some approaches in the literature– Irreversible actions (Danos&Krivine [CONCUR 2005])

» Cannot be executed backward

» Allow to make a result persistent

» Allow to model a form of (non nested) transaction

» Still most programs are divergent

– Roll operator (Lanese, Mezzina, Schmitt & Stefani [CONCUR 2011])» Allows to undo a past action and all its consequences

» If no roll points back past an action then the effect of the action is persistent

» Allow to model checkpointing

» Still most programs are divergent

External control

Not much studied yet in a concurrent setting Seems interesting in some scenarios Hierarchical component-based systems

– The father component controls the direction of execution of its child

– It needs information on the state of the child» E.g., the child should notify errors

Concurrent reversible debugger– The user controls whether the program under test should

execute backward or forward

– Backward execution in form of “undo this past action”

Semantic control

Reversibility policy embedded in the language E.g., count how many times actions have been done

and undone and always try new possibilities– Good for research in a state space

– Different euristics may improve the efficiency

Bacci, Danos & Kammar [CALCO 2011]– Steps are taken subject to some probability

– Rate depends on some energy parameters

– There is a lower bound on energy allowing to commit a forward computation in finite average time

How to avoid divergence?

With internal control perfect reversibility leads to divergence

– When I go back to a past state I can always go forward again along the same path

I want reversibility but not perfect reversibility– I go back, but I change something in the state

– To remember past tries and learn from them

– We advocate the use of compensations» From database and business process management

– Compensation: ad hoc piece of code executed in case of error to go back to a consistent state

Roadmap

Reversibility and

concurrency

Controlling reversibility

Compensations

Conclusions

Compensations and reversibility

Perfect reversibility– A;P : do A, then do P

– If P contains a rollback of A we go back to A;P

– We may redo the same error again, possibly forever

I add compensations to actions– A%B;P: do A (with compensation B), then do P

– If P contains a rollback of A we go to B;P

– Different state than before, hopefully no error now

Different kinds of compensations

Consider we want to compensate a failed booking of an airplane

Standard compensation: get back the money paid– Done automatically in a reversible setting

Replacing compensation: try again, with a different approach

– Try to book using a different airline

Tracing compensation: remember the experience and learn from it

– Remember that the tried airline is not good

Not only a matter of flavor

Consider nested transactions E.g., airline booking part of travel booking In case of travel failure

– replacing compensations should be eliminated

– tracing compensations should be preserved

Difference related to their interaction with the causality structure of the computation

Roadmap

Reversibility and

concurrency

Controlling reversibility

Compensations

Conclusions

Summary

A classification of possible ways of controlling reversibility

A description of how to combine reversibility and compensations

A classification of different flavors of compensations

Future work

Many threads of research outlined here, still to be completed Making real concurrent languages reversible

– Concurrent ML? Erlang? Java?

Fully explore the design space of controlled reversibility– External control

– Other primitives for internal control» Combining irreversible actions and rollback

– Euristics for semantic control

Studying a language with rollback and compensations– Semantics

– Behavioral theory

– Applying it to recover existing error recovery frameworks

Finally