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

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

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

12. 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. 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 and frequently visited.

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

15. 15 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. a b c d e f k l i j h g D E F A B C

16. 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. 17 Self-Stabilization Preserving Compiler

18. 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. 19 Abstract State Machine lang.  Program := Variable definition. Set of rules:  Upon do  Rule’s body is executed in finite time.

20. 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 Q behaves the same when started in the initial state. What if Q reaches an unexpected state?

21. 21 Trivial Example  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. mov ax, 10 mov cx, 0 loop1: push cx call f inc cx cmp cx,ax jne loop

22. 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. 23 Stabilization Preserving Compiler – a closer look  State space of P Ensuring that Q eventually behaves as P:  State space of Q

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

25. 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. 26 Conclusions (Part 2)  Self Stabilization preserving compiler. Language with clear semantics from any state. Innovative demands from compiler.

27. 27