Formal Models for Programming and Composing Correct Distributed Systems

Formal Models for Programming and Composing Correct Distributed Systems

Jury :

Gordon Blair Fabienne Boyer Eric Madelaine Pascal Poizat Michel Riveill Davide Sangiorgi Alan Schmitt

Ludovic HenrioHabilitation thesis (HDR)

OASIS TeamOASIS TeamINRIA – UNS – I3S – CNRS INRIA – UNS – I3S – CNRS Sophia AntipolisSophia Antipolis

Agenda

2

I. Introduction: Formal Methods

II. A Distributed Component Model

III. Behavioural Specification

IV. Dynamicity

V. A Few Hot Topics

My objective

Help the programmer write correct distributed applications, and run them safely.

•By designing languages and middlewares•By proving their properties•By providing tools to support the development and proof of correct programs

3

Programming easily correct concurrent programs is still a challenge - ERC Bertrand Meyer:

“devise a powerful, efficient and secure concurrent solution to address the needs of the programming community”

Distributed programming is even more difficult, and more and more useful (cloud computing, service oriented computing …)

Programming easily correct concurrent programs is still a challenge - ERC Bertrand Meyer:

“devise a powerful, efficient and secure concurrent solution to address the needs of the programming community”

Distributed programming is even more difficult, and more and more useful (cloud computing, service oriented computing …)

What are Formal Methods (here)?

• Mathematical techniques for developping computer-based systems: Programs Languages Systems

• What tools? Pen and paper (PP) Theorem proving (TP) = proof assistant Model checking (MC) = check a formula on (an

abstraction of) all possible executions …

4

For what?

For proving properties / correctness of

•Languages (ASPTP+PP, algorithmic skeletonsPP)

•Programs (work on behavioural specificationMC)

•Algorithms (CANTP)

•Middleware (future update strategiesTP, component platformTP, fault-tolerancePP)

•… Increase the confidence people have in the system Help my colleagues implement correct (and efficient)

middlewares Help the programmer write, compose, and run correct and

efficient distributed programs

Increase the confidence people have in the system Help my colleagues implement correct (and efficient)

middlewares Help the programmer write, compose, and run correct and

efficient distributed programs

5

My general approach

6

Programmingmodel and definitions

Programmingmodel and definitions OptimizationsOptimizations

ImplementationImplementation

OptimizationsOptimizations

Verification and tools

Verification and tools

Generic Generic propertiesproperties

7





Verification toolsVerification tools


definiti

ons

definiti

ons

properti

es

properti

es

Definitions and Properties are easy to understand


check the proofs

check the proofs

My general approach

8





Verification toolsVerification tools


definiti

ons

definiti

ons

properti

es

properti

es



My general approach

Agenda

9

What are Components?

10

Business code

Primitive component

Server / input

Client/ output

What are Components?

11

Business code

Primitive component

Business code

Primitive component

Composite component

Grid Component Model (GCM) An extension of Fractal for Distributed computing

Grid Component Model (GCM) An extension of Fractal for Distributed computing

But what is a Good size for a (primitive) Component?

Not a strict requirement, but somehow imposed by the model design•According to CCA or SCA, a service (a component contains a provided business function)•According to Fractal, a few objects •According to GCM, a process

12GCM: A Grid Extension to Fractal for Autonomous Distributed Components - F. Baude, D. Caromel, C. Dalmasso, M. Danelutto, V. Getov, L. Henrio, C. Pérez - Annals of Telecom. - 2008

In GCM/ProActive,

1 Component (data/code unit) = 1 Active object (1 thread = unit of concurrency)

= 1 Location (unit of distribution)

In GCM/ProActive,

1 Component (data/code unit) = 1 Active object (1 thread = unit of concurrency)

= 1 Location (unit of distribution)

A Primitive GCM Component

13

CI.foo(p)

In ProActive/GCM a primitive component is an active object

Primitive components communicating by asynchronous requests on interfaces Components abstract away distribution and concurrency

In ProActive/GCM a primitive component is an active object

Primitive components communicating by asynchronous requests on interfaces Components abstract away distribution and concurrency

CI

Futures for Components

14

f=CI.foo(p)……….g=f+3g=f+3 Component are independent entities

(threads are isolated in a component)+

Asynchronous requests with results

Futures are necessary

Component are independent entities (threads are isolated in a component)

+Asynchronous requests with results

Futures are necessary

1

2

3

First-class Futures

15

f=CI.foo(p)

………CI.foo(f)CI.foo(f)

Only strict operations are blocking (access to a future) Communicating a future is not a strict operation

In ProActive and ASP, futures are created and accessed implicitly (no explicit type “future”)

IN contrast with Creol, Jcobox, ...

Only strict operations are blocking (access to a future) Communicating a future is not a strict operation

In ProActive and ASP, futures are created and accessed implicitly (no explicit type “future”)

IN contrast with Creol, Jcobox, ...

First-class Futures and Hierarchy

… … …

Without first-class futures, one thread is systematically blocked in the composite component.

A lot of blocked threadsIn GCM/ProActive systematic deadlock

Without first-class futures, one thread is systematically blocked in the composite component.

A lot of blocked threadsIn GCM/ProActive systematic deadlock

return C1.foo(x)return C1.foo(x)

16

Back to Formal Methods:a Framework for Reasoning on Components• Formalise GCM in a theorem prover (Isabelle/HOL )

Component hierarchical Structure

• Bindings, etc…• Design Choices

Suitable abstraction level Suitable representation (List / Finite Set, etc …)

• Basic lemmas on component structure

17

Business code

Business code

Primitive component

Primitive component

Composite component

A semantics of Primitive Components

• Primitive components are defined by interfaces plus an internal behaviour, they can: emit requests serve requests send results receive results (at any time) do internal actions

some rules define a

correct behaviour,

e.g. one can only send result for a served request

18

Communication inside Composites

19

• Composites only delegate calls between components• Use the bindings to know where to transmit requests• Component system behaviour is expressed as a small step semantics, and specified on paper and in Isabelle/HOL

A Framework for Reasoning on Component CompositionLudovic Henrio, Florian Kammüller, and Muhammad Uzair Khan - FMCO 2009, Springer

Future Update Strategies (Muhammad Khan)

• How to bring future values to components that need them?• A “naive” approach: Any component can receive a value for

a future reference it holds. • More operational is the lazy approach:

20

require future value

Eager home-based future update

• avoids to store future values indefinitely• Relies on future registration

21

register future

register future

Results sent as soon as available

Every component with future reference is registered

Un-necessary transfers

Garbage collection of computed results possible

Formalised in Isabelle


Every component with future reference is registered

Un-necessary transfers

Garbage collection of computed results possible

Formalised in IsabelleFirst Class Futures: Specification and Implementation of Update Strategies L. Henrio, Muhammad U. Khan, Nadia Ranaldo, Eugenio Zimeo CoreGRID@Europar 2010.

Properties on Future updates

• Future updates remove all references to a given future

• All Future references are registered during reduction

register future

Garbage collectableGarbage

collectable

Complete

registration

Complete

registration

Ludovic Henrio and Muhammad Uzair Khan “Asynchronous Components with Futures: Semantics and Proofs in Isabelle/HOL” - FESCA 2010 - ENTCS

22

A refined GCM model in Isabelle/HOL

• More precise than GCM, give a semantics to the model:

asynchronous communications: future / requests request queues no shared memory between components notion of request service

• More abstract than ProActive/GCM

can be multithreaded no active object, not particularly object-oriented

23

Similarities with: SCA and Fractal (structure), Creol (futures)

A guide for implementing and proving properties of

component middlewares

A guide for implementing and proving properties of

component middlewares

Agenda

24

How to ensure the correct behaviour of a given program?

• Theorem proving too complicated for the ProActive programmer

• Our approach: behavioural specification

25

Service methods Service methods

pNets:

Behavioural Models for Distributed Fractal Components Antonio Cansado, Ludovic Henrio, and Eric Madelaine - Annals of Telecommunications - 2008

Trust the implementation step Or static analysis Generate correct (skeletons of) components

(+static and/or runtime checks)

Trust the implementation step Or static analysis Generate correct (skeletons of) components

(+static and/or runtime checks)

Use-case: Fault-tolerant storage

26

• 1 composite component with 2 external services Read/Write.

• The service requests are delegated to the Master.

• 1 multicast interface sending write/read/commit requests to all slaves.

• the slaves reply asynchronously, the master only needs enough coherent answers to terminate

Verifying Safety of Fault-Tolerant Distributed Components Rabéa Ameur-Boulifa, Raluca Halalai, Ludovic Henrio, and Eric Madelaine - FACS 2011

Full picture: a pNet

27

!Q_Write(b)

?Q_Write(x)

Basic pNets: parameterized LTS

28

Labelled transition systems, with:•Value passing•Local variables•Guards….

Can be written as a UML diagram

Eric MADELAINE

Properties proved

• Reachability(*):

1- The Read service can terminate

fid:nat among {0...2}. b:bool.∃ <true* . {!R_Read !fid !b}> true

2- Is the BFT hypothesis respected by the model ?

< true* . 'Error (NotBFT)'> true

• Termination:

After receiving a Q_Write(f,x) request, it is (fairly) inevitable that the Write services terminates with a R_Write(f) answer, or an Error is raised.

• Functional correctness:

After receiving a ?Q_Write(f1,x), and before the next ?Q_Write, a ?Q_Read requests raises a !R_Read(y) response, with y=x

(*) Model Checking Language (MCL), Mateescu et al, FM’08

29

Prove generic properties like absence of deadlock or properties specific to the application logic

Prove generic properties like absence of deadlock or properties specific to the application logic

Recent advances in behavioural specification for GCM

• Scaling-up : gained orders of magnitude by a combination of: data abstraction, compositional and contextual minimization, distributed state-space generation.

• Specified formally the whole generation process (in progress)

30

pNet

s: 2

004-

2008

CoC

oME:

hie

r. &

syn

ch.

FAC

S’08

: 1st c

lass

futu

res

WC

SI’1

0: g

roup

com

mun

icat

ion

FAC

S’11

: GC

M &

mul

ticas

t int

erfa

ces

App

licat

ion

to B

FT

Mor

e to

com

e ?

Rec

onfig

urat

ion.

..

Agenda

31

Adaptation in the GCM

• Functional adaptation: adapt the architecture + behaviour of the application to new requirements/objectives

• Non-functional adaptation(Paul Naoumenko): adapt the architecture of the container+middleware to changing environment/NF requirements (QoS …)

Additional support for reconfiguration(Marcela Rivera):

• A stopping algorithm for GCM components

• A Scripting language for reconfiguring distributed components

32A Component Platform for Experimenting with Autonomic CompositionFrançoise Baude, Ludovic Henrio, and Paul Naoumenko. Autonomics 2007.

Both functional and non-functional adaptation are expressed

as reconfigurations

Language support for distributed reconfiguration:

GCM-script

A platform for designing and running autonomic components

Both functional and non-functional adaptation are expressed

as reconfigurations

Language support for distributed reconfiguration:

GCM-script

A platform for designing and running autonomic components

Formalising Reconfiguration (preliminary)

• In our Isabelle/HOL model component structure known at runtime Two reconfiguration primitives formalised (remove and

replace) Illustrates the flexibility of the approach Basic proofs

• In our pNets model Old results (Tomas): start/stop/bind for Fractal

components Concerning GCM: formalisation and experiments in

progress

33

Agenda

34

Correct component reconfigurationTowards safety and autonomicity

• Verify reconfiguration procedures (Nuno Gaspar)

• Safe adaptation procedures as a solid ground for autonomic applications

• Some directions: Parameterized topologies: ADL[N] ; behavioural specification

(pNets) ; reconfiguration primitives (Alexandra Savu) Use of theorem proving + prove equivalence between the

Isabelle GCM model and the behavioural specification prove and use generic properties of

reconfiguration procedures

35

Correct component reconfigurationTowards safety and autonomicity

• Verify reconfiguration procedures (Nuno Gaspar)

• Safe adaptation procedures as a solid ground for autonomic applications

• Some directions: Parameterized topologies: ADL[N] ; behavioural

specification (pNets) ; reconfiguration primitives (Alexandra Savu)

Use of theorem proving + prove equivalence between the Isabelle GCM model and the behavioural specification

prove and use generic properties of reconfiguration procedures

36

[N]

Multi-active objects

• Mono-threaded active objects have limitations: Deadlocks Inadapted to multicore architecture (no shared

memory)• Solutions in the active-object community:

Jcobox: « cooperative multithreading », only one thread active at a time (release points)

JAC: Java annotations for Concurrency – real multithreading, not distributed

• Our proposal, a programming model that mixes local parallelism and distribution with high-level programming constructs

37Adapting Active Objects to Multicore Architectures - Ludovic Henrio, Fabrice Huet, Zsolt István, and Gheorghen Sebestyén - ISPDC 2011

Primitive GCM Component

38

foo() {…CI.foo(p) }

Primitive Multi-Active GCM Component

39

add() {…… }

monitor(){…… }

add() {CI.foo(p)}

Provided add, add and monitor are compatible

join

()

Proposal – Annotation Example

Groups (Collection of related methods)

Rules (Compatibility relationships between groups)

Memberships(To which group each method belongs)

40

• Implemented multi-active objects above ProActive• Added dynamic compatibility rules• Used on case studies (NAS, CAN)• Specified the semantics of Multi-ASP• Proved first properties, i.e., the semantics guarantees

that two requests executed in parallel are compatible

• Next steps: Publish the model Formalisation in Isabelle/HOL Use the new model Prove stronger properties (confluence?)

Results / Status

41

CAN dissemination algorithm (Francesco Bongiovani)

• CANs are P2P networks organised in a cartesian space of N-dimensions (used for RDF data-storage)

• Objective: disseminate efficiently information (no duplicate)• Designed an efficient algorithm (tested)• Proved the existence of an

efficient broadcast in Isabelle

Next steps:• Prove the designed algorithm

is efficient• Conduct large-scale

experiments• Study churns

42

K

FA

C

E G

H

I B J

DD

E

C

K G

H

JBI

F

Mechanical Support for Efficient Dissemination on the CAN Overlay Network - Francesco Bongiovanni, and Ludovic Henrio - CFSE 2011

What I could not fit in this talk

• ASP: Active object calculus

• ASPfun a functional variant formalised in Isabelle (typing)

• Fault tolerance (Christian Delbé) and garbage collection (Guillame Chazarain) for active objects

• Work on behavioural skeletons (typing and exceptions) (Mario Leyton)

• JDC: a language for specifying behaviour of components (Antonio Cansado)

• Details on the behavioural specification of components and active objects (first-class futures, …)

And of course, a lot of inference rules and greek letters …

43

THANK YOU !

44

Eric Madelaine

Antonio Cansado

Marcela Rivera

Paul Naoumenko

Muhammad Khan

Boutheina Bannour

Florian Kammueller

Françoise Baude

CoreGrid partners

Denis Caromel

Bernard Serpette

Special thanks to the people I worked with, mainly:

Mario Leyton

Christian DelbéFrancesco Bongiovani

Fabrice Huet

Zsolt Istvan

Rabéa BoulifaAnd others !!!

Guillaume Chazarain

Tomas Barros

Primitive Components in Isabelle

• Primitive components are defined by interfaces plus an internal behaviour, they can: emit requests serve requests send results receive results (at any time) do internal actions

some rules define a

correct behaviour,

e.g. one can only send result for a served request• We define the behaviour of the whole components as small-

step operational semantics

46A Framework for Reasoning on Component CompositionLudovic Henrio, Florian Kammüller, and Muhammad Uzair Khan - FMCO 2009, Springer

Non-functional Component Structure

• Non-functional aspects as a composition of components (inside a membrane) A component structure for the membrane New kind of interfaces and bindings An API for reconfiguring

the membrane Non-functional code is

components or objects distributed or not

• Towards autonomiccomponents

47A Component Platform for Experimenting with Autonomic CompositionFrançoise Baude, Ludovic Henrio, and Paul Naoumenko. Autonomics 2007.

Triggering Distributed Reconfigurations in the Scripting Language

• Fscript is a language to reconfigure Fractal components• A primitive for the distributed script interpretation

• + other minor extensions

48

Reconfiguration interface

action(arguments)

Inte

rpre

ter

target_component

remote_call(target_component, action_name, parameters, ...);

definition action1

...

remote_call(C2,’action2’)



...

definition action12

...


... Interpreter Membrane

C2

RC 1

RC 12

RC 121

RC 2

RC 11

Reconfiguration scripts

C11

Example

49


definition action1

...




...

definition action12

...


... Interpreter

RC 1

RC 12

RC 121

RC 2

RC 11

C121

C11

C12

Example

50

action1( )


Membrane

C2Reconfiguration scripts

definition action1

...




...

definition action12

...


... Interpreter

RC 1

RC 12

RC 121

RC 2

RC 11

C121

C11

C1

C12

Example

51

action1( )

action11( )

action2( )

action12( )


Membrane

C2Reconfiguration scripts

The reconfiguration script is executed in a parallel and

distributed manner

This language is the basis of the GCM-script language

The reconfiguration script is executed in a parallel and

distributed manner

This language is the basis of the GCM-script language

A Reconfiguration Framework for Distributed ComponentsMarcela Rivera, Ludovic Henrio and Boutheina Bannour. SINTER Workshop 2009

Can we do more dynamicity?

• YES: ProActive/ASP!• Active objects:

newActive Reference to active objects passed as request

parameters or replies• What formal models/properties

ASP(old): confluence and determinacy (POPL 2004, I&C) future updates can occur at any time, execution uniquely characterised by the order of request senders

Fault tolerance (Europar’05, PPoPP’07)

ASPfun: in Isabelle/HOL, typed, proved progress, studied binder representations (SCP 2011)

Behavioural specification: possible but much more restricted (need strong static analysis)

52

GCM Formalisation in Isabelle

• > 4000 lines, mostly proofs (do not read the proofs!)

• Almost 300 lemmas and theorems,

• ~ 500 lines definitions: component model and semantics

• 1800 lines for future update specific properties

• A few tricky design choices (lists vs sets, how to store names, …)

• A couple of axioms remaining (reduction correctness)

short-term goal: correctness of various strategies

Longer term: reconfiguration and execution

53

Support Constructs and Lemmas

• Operators to manipulate components inside hierarchies E.g., Traverse hierarchy: find/replace,

(recursive) set of subcomponents: cpSet

• To manipulate states Retrieve referenced futures, all computed results, etc

• Properties on component structure “Well-defined” and “correct” Components

• Support lemmas, e.g.

54

Component re-configuration

• Transformation of component structure or content at runtime Two reconfiguration primitives formalised (remove and

replace) Illustrates the flexibility of the approach

Basic properties on reconfiguration primitivesLudovic Henrio, Florian Kammüller, and Muhammad Uzair Khan A Framework for Reasoning on Component Composition - FMCO 2009, Springer (2010)

55

Eager forward-based strategy

• A strategy avoiding to store future values indefinitely• Future updates follow the same path as future flow• Each component remembers only the components to

which it forwarded the future

56


No additional message

Future updates form a chain intermediate components

Easy to garbage collect computed results


No additional message

Future updates form a chain intermediate components

Easy to garbage collect computed results

GCM-like Component with Eager-home

57

Composite Component Semantics –CommChild

58

What is a Future?• Future = Placeholder for an awaited result• Creation of a future

How and when are futures created? Implicit creation = automatic upon asynchronous

invocation (on a remote object) Explicit creation = there is a future construct

• Manipulation and access How to manipulate the futures?

Explicit access = get operation (+ future type) Implicit (transparent) access = any variable can

contain a future

59

Formal Models for Programming and Composing Correct Distributed Systems

Documents

Transcript of Formal Models for Programming and Composing Correct Distributed Systems