Self-Stabilization An Introduction Aly Farahat Ph.D. Student Automatic Software Design Lab Computer Science Department Michigan Technological University

10/14/2009Automatic Software Design Lab2 The ability of a system to resume its ‘legal behavior’ regardless of its initial state, in a finite number of steps

10/14/2009Automatic Software Design Lab3 Contents Basic Concepts Self-Stabilizing Operating System Design of Self-Stabilization

10/14/2009Automatic Software Design Lab4 Basic Concepts

10/14/2009Automatic Software Design Lab5 Properties of Self-Stabilization Closure Program execution remains in a set of legitimate states (i.e., invariant) in the absence of faults Convergence Any computation has a suffix entirely confined within the set of legitimate states

10/14/2009Automatic Software Design Lab6 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/2009Automatic Software Design Lab7 Program’s Execution

10/14/2009Automatic Software Design Lab8 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/2009Automatic Software Design Lab9 Dijkstra’s Token-Ring P 1 : x 1 ==x N  x 1 :=(x N +1)mod N P i>1 : x i ≠x i-1  x i :=x i-1 N: Number of processes x i : Variable associated with P i

10/14/2009Automatic Software Design Lab10 Self-Stabilizing Operating System

10/14/2009Automatic Software Design Lab11 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/2009Automatic Software Design Lab12 Solution Foundations General ideas: –Continuous Monitoring and Consistency Enforcement –Reset SS components of an OS: –Loader –Scheduler –Code Portions in ROM

10/14/2009Automatic Software Design Lab13 Design of Self-Stabilization

10/14/2009Automatic Software Design Lab14 Complex task –In part because there is no central point of control Automation is one way to facilitate the design of SS

10/14/2009Automatic Software Design Lab15 Research Problem

10/14/2009Automatic Software Design Lab16 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/2009Automatic Software Design Lab17 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/2009Automatic Software Design Lab18 Token-Ring R/W Restrictions

10/14/2009Automatic Software Design Lab19 Token-Ring Design Fault-Intolerant Token Ring Resolve Deadlock states Consider R/W Restrictions Do not add cycles

10/14/2009Automatic Software Design Lab20 Further Readings -E. W. Dikjstra, “Self-stabilization in spite of distributed control,” In Selected Writings on Computing: a Personal Perspective. Springer- Verlag, Berlin, 1982, Originally Published in A. Arora & M. G. Gouda, “Closure and convergence: a foundation of fault-tolerant computing.” In Proceedings of the 22 nd International Conference On Fault-Tolerant Computing Systems, S. Dolev & R. Yagel, “Toward self-stabilizing operating systems,” In Proceedings of the 2 nd International Workshop on Self-Adaptive and Autonomic Computing Systems (SAACS’04), Zaragoza, Spain, pp , 2004

10/14/2009Automatic Software Design Lab21 Thank you!

10/14/2009Automatic Software Design Lab22 Bottlenecks State Space explosion Considering: –Cycle Resolution –Deadlock Resolution –Read Restrictions (grouping of transitions)‏ Is Hard!

10/14/2009Automatic Software Design Lab23 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/2009Automatic Software Design Lab24 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/2009Automatic Software Design Lab25 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/2009Automatic Software Design Lab26 Ranking States We rank the states outside the invariant based on write-restrictions only Ranks Construction: –Rank 0 = def Invariant –i.e: There exists a process who can modify the state in Rank i by atomically writing its own variables to reach a state of Rank i-1. –Rank n : States directly reaching Rank n-1 and unreachable by non-ranked states. This is a backward reachability analysis using “Onion Rings” [Gentilini et al.]

10/14/2009Automatic Software Design Lab27 Ranking in a (barrier synchronization example)‏

10/14/2009Automatic Software Design Lab28 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/2009Automatic Software Design Lab29 Future Work Parallelizing synthesis algorithms Compositional synthesis of self- stabilization

10/14/2009Automatic Software Design Lab30 Token-Ring (cont’)‏ A Guard for P i evaluates to true when P i has the token Legal States (Invariant): Only 1 process has the token Illegal State: More than one process has a token

10/14/2009Automatic Software Design Lab31 Generalized Self-Stabilization Q leads-to P [Arora] In our case (Q is the constant predicate True)‏