Self-StabilizationAn Introduction

Aly FarahatPh.D. Student

Automatic Software Design Lab Computer Science Department

Michigan Technological University

10/14/2009 Automatic Software Design Lab 2

The ability of a system to resume its ‘legal behavior’ regardless of its initial state, in a

finite number of steps

10/14/2009 Automatic Software Design Lab 3

Contents

• Basic Concepts

• Self-Stabilizing Operating System

• Design of Self-Stabilization

10/14/2009 Automatic Software Design Lab 4

Basic Concepts

10/14/2009 Automatic Software Design Lab 5

Properties of Self-Stabilization

• ClosureProgram execution remains in a set of legitimate

states (i.e., invariant) in the absence of faults

• ConvergenceAny computation has a suffix entirely confined

within the set of legitimate states

10/14/2009 Automatic Software Design Lab 6

Motivation

• No need for initialization

• Recovery after faults stop occurring

• Little assumption about a fault-model (transient faults)

• Captures a family of fault-tolerant systems

10/14/2009 Automatic Software Design Lab 7

Program’s Execution

Invariant

Program’s State Space

10/14/2009 Automatic Software Design Lab 8

Invariant

• A set of states from where program executions meet its requirements– a.k.a set of legitimate states

– E.g., the non-faulty nodes in a network should remain connected

• Assuming no faults: the program’s state in any computation is in the invariant.

10/14/2009 Automatic Software Design Lab 9

Dijkstra’s Token-Ring

P1: x1==xN x1:=(xN+1)mod N

Pi>1: xi≠xi-1 xi:=xi-1

N: Number of processes

xi: Variable associated with Pi

P1

P2

P3

P4

0

0

0

0

P1

P2

P3

P4

1

0

0

0

P1

P2

P3

P4

1

1

0

0

P1

P2

P3

P4

1

1

1

0

P1

P2

P3

P4

1

1

1

1

P1

P2

P3

P4

2

1

1

1

P1

P2

P3

P4

2

2

1

1

P1

P2

P3

P4

2

2

2

1

P1

P2

P3

P4

2

2

2

2

P1

P2

P3

P4

3

2

2

2

P1

P2

P3

P4

3

3

2

2

P1

P2

P3

P4

3

3

3

2

P1

P2

P3

P4

3

3

3

3

P1

P2

P3

P4

0

3

3

3

P1

P2

P3

P4

0

0

3

3

P1

P2

P3

P4

0

0

0

3

P1

P2

P3

P4

0

0

0

0

P1

P2

P3

P4

3

1

3

2

P1

P2

P3

P4

3

1

3

3

P1

P2

P3

P4

3

1

1

3

P1

P2

P3

P4

3

3

1

3

P1

P2

P3

P4

0

3

1

3

P1

P2

P3

P4

0

3

1

1

P1

P2

P3

P4

0

3

3

1

P1

P2

P3

P4

0

0

3

1

P1

P2

P3

P4

0

0

3

3

P1

P2

P3

P4

0

0

0

3

10/14/2009 Automatic Software Design Lab 10

Self-Stabilizing Operating System

10/14/2009 Automatic Software Design Lab 11

SS Operating Systems

• Need for self-organizing OS

• Defines – a model for the processor execution– a model for system execution– the aggregate system state and self-

stabilization (High-atomicity)

10/14/2009 Automatic Software Design Lab 12

Solution Foundations

• General ideas:– Continuous Monitoring and Consistency

Enforcement– Reset

• SS components of an OS:– Loader– Scheduler– Code Portions in ROM

10/14/2009 Automatic Software Design Lab 13

Design of Self-Stabilization

10/14/2009 Automatic Software Design Lab 14

• Complex task– In part because there is no central point of

control

• Automation is one way to facilitate the design of SS

10/14/2009 Automatic Software Design Lab 15

Research Problem

SynthesisTool

(Input)

1-Non Self-Stabilizing Program

2-The Invariant

(Output)-

A Self-Stabilizing Program

10/14/2009 Automatic Software Design Lab 16

Write Restrictions

– Transitions belonging to a specified process

are allowed to write only a proper subset of the state variables

– Effect: transitions writing a “non-subset” of the write variables are not included in this process

10/14/2009 Automatic Software Design Lab 17

Read Restrictions

– Transitions belonging to a specified process are allowed to read only a proper subset of the state variables

– Effect: each transition in this process has group-mates originating at source states with unreadable variables as “don’t cares”

10/14/2009 Automatic Software Design Lab 18

Token-Ring R/W Restrictions

000 100 200

010 110 210

020 120 220

001 101 201

011 111 211

021 121 221

002 102 202

012 112 212

022 122 222

P1-G1

P1-G1

P1-G1

P1-G2

P1-G2

P1-G2

P1-G3

P1-G3

P1-G3

000 100 200

010 110 210

020 120 220

001 101 201

011 111 211

021 121 221

002 102 202

012 112 212

022 122 222

P1-G1

P1-G1

P1-G1

P1-G2

P1-G2

P1-G2

P1-G3

P1-G3

P2-G1

P2-G1

P2-G1

000 100 200

010 110 210

020 120 220

001 101 201

011 111 211

021 121 221

002 102 202

012 112 212

022 122 222

P1-G1

P1-G1

P1-G1

P1-G2

P1-G2

P1-G2

P1-G3

P1-G3

P2-G1

P2-G1

P2-G1

P2-G2

P2-G2

P2-G2

P2-G3

P2-G3

P2-G3

000 100 200

010 110 210

020 120 220

001 101 201

011 111 211

021 121 221

002 102 202

012 112 212

022 122 222

P1-G1

P1-G1

P1-G1

P1-G2

P1-G2

P1-G2

P1-G3

P1-G3

P2-G1

P2-G1

P2-G1

P2-G2

P2-G2

P2-G2

P2-G3

P2-G3

P3-G1 P3-G1 P3-G1

P3-G2 P3-G2 P3-G2

P3-G3 P3-G3 P3-G3

10/14/2009 Automatic Software Design Lab 19

Token-Ring Design

• Fault-Intolerant Token Ring

• Resolve Deadlock states

• Consider R/W Restrictions

• Do not add cycles

000 100 200

010 110 210

020 120 220

001 101 201

011 111 211

021 121 221

002 102 202

012 112 212

022 122 222

000 100 200

010 110 210

020 120 220

001 101 201

011 111 211

021 121 221

002 102 202

012 112 212

022 122 222

000 100 200

010 110 210

020 120 220

001 101 201

011 111 211

021 121 221

002 102 202

012 112 212

022 122 222

000 100 200

010 110 210

020 120 220

001 101 201

011 111 211

021 121 221

002 102 202

012 112 212

022 122 222

000 100 200

010 110 210

020 120 220

001 101 201

011 111 211

021 121 221

002 102 202

012 112 212

022 122 222

000 100 200

010 110 210

020 120 220

001 101 201

011 111 211

021 121 221

002 102 202

012 112 212

022 122 222

10/14/2009 Automatic Software Design Lab 20

Further Readings

- E. W. Dikjstra, “Self-stabilization in spite of distributed control,” In Selected Writings on Computing: a Personal Perspective. Springer-Verlag, Berlin, 1982, 41-46. Originally Published in 1973

- A. Arora & M. G. Gouda, “Closure and convergence: a foundation of fault-tolerant computing.” In Proceedings of the 22nd International Conference On Fault-Tolerant Computing Systems, 1992

- S. Dolev & R. Yagel, “Toward self-stabilizing operating systems,” In Proceedings of the 2nd International Workshop on Self-Adaptive and Autonomic Computing Systems (SAACS’04), Zaragoza, Spain, pp. 684-688, 2004

10/14/2009 Automatic Software Design Lab 21

Thank you!

10/14/2009 Automatic Software Design Lab 22

Bottlenecks

• State Space explosion

• Considering:– Cycle Resolution– Deadlock Resolution– Read Restrictions (grouping of transitions)

Is Hard!

10/14/2009 Automatic Software Design Lab 23

Self-Stabilization in High Atomicity

• Definitions:– Global Predicate: A Boolean function of all state variables– Local Predicate: A predicate on a process locally readable

variables

• High Atomicity:– All variables are atomically readable by any process – Global predicates are detectable in any process

• Recovery is ensured at most in N steps under write-only restrictions– N: the number of distributed processes

10/14/2009 Automatic Software Design Lab 24

Self-Stabilization in Low-Atomicity

• Read Restrictions: Local actions affecting global behavior

• The invariant is not detectable in each component due to read-restrictions

• Grouping: transitions are grouped for all unreadable variables

10/14/2009 Automatic Software Design Lab 25

Handling Bottlenecks

• State Explosion: Use of symbolic methods– Currently we are using BDD libraries

• Cycle Resolution: symbolic SCC detection algorithms [Gentilini et al.]– We are investigating properties of directed

graphs to resolve cycles in SCC’s

• Hardness: use heuristic search and sound but incomplete algorithms

10/14/2009 Automatic Software Design Lab 26

Ranking States

• We rank the states outside the invariant based on write-restrictions only

• Ranks Construction:– Rank0 =def Invariant– i.e: There exists a process who can modify the state

in Ranki by atomically writing its own variables to reach a state of Ranki-1.

– Rankn: States directly reaching Rankn-1 and unreachable by non-ranked states.

This is a backward reachability analysis using “Onion Rings” [Gentilini et al.]

10/14/2009 Automatic Software Design Lab 27

Ranking in a (barrier synchronization example)f, f, f

f,e,fe,f,f f,f,e

e,e,fi,f,f e,f,e f,i,f f,e,e f,f,i

A12

A22 A32

A11

A22A32 A12

A12A21 A32 A

22

A31

e,e,e

A12

A22A32

i,e,e e,i,e e,e,i

A11

A21 A31

i,i,e i,e,i e,i,i

A21

A31 A11

A21

A31A11

i,i,i

A21

A11A31

f,i,i i,f,i i,i,f

A13 A23 A33

A13

A23

A33

A23

A13

A33

A13

A33

A23

A13

A23A33

A12

A22

A32 Non-Progress Cycle of P3

Progress Transition

Non-Progress Cycle of P1

Non-Progress Cycle of P2

Rank 0

Rank 1

Rank 2

Rank 3

Rank 4

Rank 5

Rank 6

Rank 7

f, f, f

f,e,fe,f,f f,f,e

e,e,fi,f,f e,f,e f,i,f f,e,e f,f,i

A12

A22 A32

A11

A22A32 A12

A12A21 A32 A

22

A31

e,e,e

A12

A22A32

i,e,e e,i,e e,e,i

A11

A21 A31

i,i,e i,e,i e,i,i

A21

A31 A11

A21

A31A11

i,i,i

A21

A11A31

f,i,i i,f,i i,i,f

A13 A23 A33

A13

A23

A33

A23

A13

A33

A13

A33

A23

A12

A22

A32 Non-Progress Cycle of P3

Progress Transition

Non-Progress Cycle of P1

Non-Progress Cycle of P2

Rank 0

Rank 1

Rank 2

Rank 3

Rank 4

Rank 5

Rank 6

Rank 7

f, f, f

f,e,fe,f,f f,f,e

e,e,fi,f,f e,f,e f,i,f f,e,e f,f,i

A12

A22 A32

A11

A22A32 A12

A12A21 A32 A

22

A31

e,e,e

A12

A22A32

i,e,e e,i,e e,e,i

A11

A21 A31

i,i,e i,e,i e,i,i

A21

A31 A11

A21

A31A11

i,i,i

A21

A11A31

f,i,i i,f,i i,i,f

A13 A23 A33

A13

A23

A33

A23

A13

A33

A13

A33

A23

Non-Progress Cycle of P3

Progress Transition

Non-Progress Cycle of P1

Non-Progress Cycle of P2

Rank 0

Rank 1

Rank 2

Rank 3

Rank 4

Rank 5

Rank 6

Rank 7

f, f, f

f,e,fe,f,f f,f,e

e,e,fi,f,f e,f,e f,i,f f,e,e f,f,i

A12

A22 A32

A11

A22A32 A12

A12A21 A32 A

22

A31

e,e,e

A12

A22A32

i,e,e e,i,e e,e,i

A11

A21 A31

i,i,e i,e,i e,i,i

A21

A31 A11

A21

A31A11

i,i,i

A21

A11A31

f,i,i i,f,i i,i,f

A13 A23 A33

A13

A23

A33

Rank 0

Rank 1

Rank 2

Rank 3

Rank 4

Rank 5

Rank 6

Rank 7

10/14/2009 Automatic Software Design Lab 28

Incremental addition

• We check if the original program has no cycles outside the invariant, otherwise we declare failure.

• Incrementally add recovery transitions with their group-mates, process by process and rank by rank.

• We ensure the following:– We add groups having no transitions in cycles outside

the invariant– We add groups having at least one transition

resolving deadlock states– We do not add transitions originating in the invariant

10/14/2009 Automatic Software Design Lab 29

Future Work

• Parallelizing synthesis algorithms

• Compositional synthesis of self-stabilization

10/14/2009 Automatic Software Design Lab 30

Token-Ring (cont’)

• A Guard for Pi evaluates to true when Pi has the token

• Legal States (Invariant): Only 1 process has the token

• Illegal State: More than one process has a token

10/14/2009 Automatic Software Design Lab 31

Generalized Self-Stabilization

• Q leads-to P [Arora]

• In our case (Q is the constant predicate True)