Realizing Self-Stabilizing Algorithms

1. Realizing Self-StabilizingAlgorithms Shlomi Dolev, Yinnon A. Haviv, Department of Computer Science Ben-Gurion University, Israel Mooly Sagiv, Department of Computer Science Tel Aviv University, Israel

2. Motivation • Transient malfunctions. • Single processor: • Hardware glitches. • Soft-Errors. • Distributed environment: • Processor crashes / recoveries. • Link errors. • Resulting in an unpredictable system state.

3. Coping with Transient Errors • Masking (safety factor) achieved by: • Information redundancy (e.g., ECC). • Time/Space redundancy. (e.g., TMR) • Self-Stabilization [Dijkstra74]: • Assuming any system state (caused by errors). • Recovering by converging into legal behavior. • Existing algorithms for distributed tasks: • Routing, leader election, mutual exclusion, etc.

4. Self-Stabilizing Algorithms • Used for on-going systems • The required semantics is defined by a set of traces. • Started in any given state, the system eventually exhibit a legal behavior. • Example: eventually there is exactly one leader. • Self-stabilizing algorithms are described using pseudo-code/Guarded command notations. • Our goal: practical self-stabilizing systems.

5. Realization – Outline • Self-stabilizing microprocessor [DH04]. • What is required from ss-microprocessor? • Methodologies for verifying stabilization property. • Implementation - Mic-1 • Self-stabilization preserving compiler. • Choosing the right language. • Requirements from self-stabilization preserving compiler. • Implementation - Abstract State Machines

6. More on Soft-Errors • Caused by cosmic ray. • Cause a logical gate to temporarily malfunction / latch to flip its content. • Currently noticed (and handled) only in memories (once a week / 1GB of ram). • Technology roadmaps predict a significant impact on the microprocessors soon…

7. Soft-Errors - Current Solutions • Obtaining masking using probabilistic approaches: • Information redundancy (ECC / Parity) • Space redundancy • Time redundancy • Failure detection / recovery. • Known solutions: • IBM S-390 • Compaq NonStop Himalaya • IROC

8. Side note on predicting soft-errors vulnerability. • Incorrect computation in the internal gates that does not result in an incorrect output. • Consider the formula below: When : • A formula may favor certain inputs.

9. Self-Stabilizing Algorithms – a Solution to Soft-Errors? • Self-Stabilizing algorithms assume that the microprocessor executes them. • Soft-Errors may cause the microprocessor to be stuck in a faulty state. • Remember: composing self-stabilizing algorithms creates a self-stabilizing system. • Make the microprocessor eventually fetch-decode-execute machine code.

10. Self-Stabilizing Microprocessor • A microprocessor self-stabilizes if: • Started in any internal state, it converges in a finite number of steps into the set of safe states. • Safe states, from which the microprocessor behaves as it should. • The definition of the desired behavior of the microprocessor is sensitive • Depends on the abstraction level.

11. control MAR MDR PC MBR SP LV CPP TOS OPC H Data Micro-Code Controller control MIR MPC Stack 1 bit flip flops op Code Z,N address Our Test Case – Mic-1 • Presented in Tanenbaum’s book. • Implements a subset of JVM instruction set. • Stack operations use cache for the top of stack value (TOS).

12. Alternative Specifications for ADD • Sums the top two elements in the stack and replaces them with the result • Or as a function of the TOS value: • TOS Stack[--SP]+TOS • Stack[SP]=TOS • Two specifications are different if: • TOS ≠ Stack[SP] • Conclusion: semantic change in the specification may change the set of safe states.

13. Ensuring Convergence • The state space of the microprocessor – • Every possible assignment to the machine memory elements (including internal registers). • Safe states • States in which the microprocessor behaves according to the specification. • Ultra-Safe states • Subset of the safe states that is easily defined andfrequently visited.

14. Ensuring Convergence - Alternatives • Using a self-stabilizing watchdog for ensuring ultra-safe statesare visited often enough. • Validating that there exists no “bad” cyclein the transition graph • Cycle that does not travel throw an ultra-safe state.

15. h D a g j A b E i l d B c F k C e f Proving Convergence • Proving that there exists no “bad” cycle in the transition graph of the microprocessor. • Too large ! (we must explore the entire graph) • Using an abstraction:~ Group together states in which the micro-code program counter is the same.

16. Summary (Part 1) • In addition, technique for the case of black box using a simple self-stabilizing watchdog. • Self-Stabilizing microprocessor is possible. • Specification semantics is crucial. • Abstract specification  easier to write code in. • Detailed specification  easier to implement.

17. Self-Stabilization PreservingCompiler

18. Choosing the right language • Language for describing stabilizing algorithms: • Dijkstra choose guarded commands. Why? • Simple and precise semantics from any state. • Allows abstract presentation and provable design refinements. (D)ASM – (Distributed) Abstract State Machine [Yuri Gurevich 93] Combined with Dijkstra guarded commands.

19. Abstract State Machine lang. • Program := • Variable definition. • Set of rules: • Upon <condition> do <statement> • Rule’s body is executed in finite time.

20. The Gap. • Need a transformation between: • Input program P, described using a high language, say, (D)ASM. • Output program Q, described using a machine language, say, JVM. • Existing compilers? • P and Qbehaves the same when started in the initial state. • What if Q reaches an unexpected state?

21. Trivial Example • mov ax, 10 • mov cx, 0 • loop1: • push cx • call f • inc cx • cmp cx,ax • jne loop • A statement of the form: For each i in {0..9} do f(i) • May be compiled to  • Start with cx=12 inside the loop… • Moreover: Any runtime mechanism can get stuck / inconsistent.

22. Self-Stabilization Preserving Compiler • Given P, a self-stabilizing program described in ASM, output Q, a stabilizing JVM program for the same task. • Started at any state, Q eventually behaves the same as P, when started at some state. • Requires more than existing compilers obtain.

23. Stabilization Preserving Compiler – a closer look Ensuring that Q eventually behaves as P: • State space of P • State space of Q

24. Enforce invariants Variable declarations Scheduler condition_1 … condition_n upon <condition_1> do <statement_1> Statement_1 upon <condition_n> do <statement_n> Statement_n The Transformation

25. Status and future development • Front end of compiler established. • Typed version of ASM. • JavaCC as a parser generator. • Interpreter (used as a model) • Near future: • JVM subset backend. • Integrating optimizations cleverly. • Fast stabilization vs. optimizations.

26. Conclusions (Part 2) • Self Stabilization preserving compiler. • Language with clear semantics from any state. • Innovative demands from compiler.

27. We have stabilized...