SIMULATING I/O AUTOMATA. TRACE PROPERTIES Cristian Gavril˘a and Ioan Jurca fcristig,
[email protected] University “Politehnica” of Timis¸oara Computer Science Department
Abstract I/O automaton is a mathematical model used for synchronous distributed algorithms. I/O automaton is a state machine with very little structure, and with labeled transitions. IOA language was developed for this automata. This article presents the building of a simulator for I/O automata described in a dialect of this language. The use of the simulator is to generate traces of the automata, so that we can verify some of them properties. Key words: algorithm, distributed systems, simulation. 1. Introduction Distributed algorithms are a subclass of concurrent algorithms. Originally, the term was used to refer to algorithms that were designed to run on many processors situated in wide geographical areas. But now the term includes algorithms that run on local networks and algorithms for shared memory multiprocessors. Some attributes of distributed algorithms are:
the interprocess communication (IPC) method; the timing model; the failure model; the problem addressed.
The distributed algorithms have a higher degree of uncertainty and more independence of activities compared with traditional concurrent algorithms. Generally we have an unknown number of processors, unknown network topology, independent inputs at different locations, several programs executing at once, starting at different times, and operating at different speeds. We also have uncertain message delivery times, and unknown message ordering with possible failures. For a distributed algorithm we do not try to understand everything about its behavior, but we try to understand certain selected properties of its behavior.
2. I/O automaton model I/O automaton [2, 3] is a mathematical model for the description of concurrent asynchronous systems. It facilitates a precise description of the interaction among components, and it is used to reason about the system behavior. I/O automata can be composed into more complex automata representing concurrent systems. An I/O automaton is a state machine with labeled transitions associated with actions. There are three classes of actions:
input actions – not under the control of the automaton; output actions; internal actions.
A signature S is a triple consisting of the previus sets of actions. We define acts(S) to be all the actions of S. An I/O automaton, A , has five components:
sig(A ) – signature of A ; states(A ) – states set; start (A ) – starting states set, which is a nonempty subset of states(A ); trans(A ) – ternary relation: trans(A ) states(A ) acts(sig(A )) states(A ). For every state s and every input action π, there is a transition (s π s ) 2 trans(A ); tasks(A ) – a task partition: an equivalence relation on local (sig(A )) with at most count;
;
0
ably many equivalence classes.
An execution fragment is a finite or an infinite sequence of alternating states and actions. An execution fragment beginning with a start state is called an execution. A state is said to be reachable in A if it is the final state of a finite execution of A . Often we are interested in observing only the external behavior of an I/O automaton. Thus, the trace of an execution α of A : trace(α) is the subsequence of α consisting of all external actions (input and output actions). In distributed systems we are interested only in the executions of the composed automaton where all components get fair turns to perform steps. The notion of fairness means that each task gets infinitely many opportunities to perform one of its actions. An execution fragment α is said to be fair if none of the tasks C 2 tasks(A ) are enabled in the final state of α. A trace is fair if it belongs to a fair execution. I/O automata are used not only for a more precise description of the distributed asynchronous systems, but also to formulate and prove properties of system behavior. We can consider an I/O automaton as a black box, and we can see only the automaton traces. Some properties of I/O automata are naturally formulated like trace properties or fair trace properties. A trace property P consists of the following:
sig(P ) – a signature containing no internal actions; traces(P ) – a set of finite or infinite sequences of actions in acts(sig(P )).
A trace property specifies an external interface and a set of sequences observed at that interface. Any external behavior that can be produced by the automaton A is admitted by the property P . We say that a trace property P is a trace safety property if it satisfies the following conditions: 1. traces(P ) 6= 0/ 2. traces(P ) is prefix-closed: β 2 traces(P ) β0β00 = β ) β0 2 traces(P ) 3. traces(P ) is limit-closed: β1 ; β2 ; : : : with βi prefix for βi+1 ) the unique sequence β that is the limit of the βi, is in traces(P ). A safety property is often interpreted as saying that some particular bad thing never happens. A trace property P is a trace liveness property provided that every finite sequence over acts(P ) has some extension in traces(P ). This is often informally understood as saying that some particular good thing eventually happens. 3. IOA language IOA language [1, 4] was developed for defining I/O automata and stating their properties. IOA provides simple abstract descriptions of distributed systems, invariants, and simulation relations. An IOA specification contains different kinds of units:
type definitions, used to represent state components or indices for automata; automaton definitions; assertions about automata, e.g., invariant and simulation relations.
When we define a primitive automaton, we have to describe its signature, states, transitions, and a task partition (optional). Input transitions will be described just by their effect, and local transitions (internal and output transitions) will be described by their precondition and effect. Preconditions and effects are program fragments, usually described in Larch language. In this article we consider preconditions and effects as C++ code. The following example describes in IOA language an automaton for a FIFO reliable channel: Automaton C Signature Input Send0 Input Send1 Output Receive0
Output Receive1 States Queue : Seq Transitions Input Send0 Eff Queue.Add(0); Input Send1 Eff Queue.Add(1); Output Receive0 Pre (0 == Queue.Top()); Eff Queue.Pop(); Output Receive1 Pre (1 == Queue.Top()); Eff Queue.Pop();
4. Code generator The code generator reads an I/O automaton description in IOA language and produces the code of a simulator for the automaton, in C++. The code generator is structured in three important parts:
lexical analyzer; syntactic analyzer; simulator generator.
Lexical and syntactic analysis was implemented for the whole language, but code generation is presently implemented only for primitive automata with nonparameterized actions. Standard data types of the IOA language were implemented as C++ libraries included in the simulator code. This means that data types can be easily extended or modified. The most important data structure is the symbol table, which is a hash table. Here we have actions, states and identifiers, their name and type, with an optional associated value (initial state), pointers to elements of the same kind (list of states, list of actions). 5. Simulation The simulator will read a file describing the input actions, and will generate a fair trace of execution of the automaton. The simulator is composed of two important components:
the I/O automaton described as a C++ object; a simulation kernel for the automaton.
For the automaton described in section 3, the definition of the object for the generated simulator is:
class c { public: void effsend0(void); void effsend1(void); int prereceive0(void); void effreceive0(void); int prereceive1(void); void effreceive1(void); private: seq queue; public: c(void) { } };
Preconditions are described as functions with boolean value, and effects as functions with void type. As noticed, for the input actions we are generating just the precondition functions. In the constructor we give the initial values to the state variables. The simulation kernel will execute four steps at every iteration. 1. Intercepting the input actions: i++; if(i == pos) { if(!strcmp("send1", action)) aut.effsend1(); if(!strcmp("send0", action)) aut.effsend0(); if(!feof(in)) fscanf(in, "%d%s", &pos, action); continue; }
2. Finding the enabled local actions: for(a = active = 0; a < NR_LOCAL; a++) switch(a) { case receive1: actionTable[a] = aut.prereceive1(); if(actionTable[a])
active++; break; case receive0: actionTable[a] = aut.prereceive0(); if(actionTable[a]) active++; break; default: printf("Unknown action.\n"); exit(1); }
3. Selecting an enabled action for execution: todo = random() % active; a = 0; while(todo || !actionTable[a]) { if(actionTable[a]) todo--; a++; }
4. Executing the selected action: switch(a) { case receive1: aut.effreceive1(); break; case receive0: aut.effreceive0(); break; default: printf("Unknown action.\n"); exit(1); }
When there is no local action enabled, we finish a finite fair execution. 6. Trace properties The traces generated by the simulator have some specific properties. For verifying a trace property we should prove that all the traces of the automaton verify that property. For proving that a trace property is not verified, it is enough to find a trace that does not verify that property. Proving that a trace property is not verified is easier than proving that a trace property is verified.
For the automaton described in section 3 we can prove that it does not verify the following trace property: After a send action there are an odd number of actions. To prove this we find a fair trace like: send0; receive0; send0; send1; receive0; receive1; send0; receive0
(1)
which does not satisfy this property, because after send1 action there are four actions. To prove a property we normally use formal methods. For example the property: The number of send equals the number of receive actions, can be proved with formal methods, but it can not be proved by simulation. By simulation we can achieve only some confidence in the results. 7. Conclusions I/O automaton is a very useful model in studying distributed algorithms, and simulating these models can bring important informations regarding the properties of some distributed algorithms. This simulator is a software tool for the study of asynchronous automata like reliable FIFO channels, reliable channels with messages reordering, channels with failures, process automata, broadcast channels, multicast channels. These automata can be composed, in order to study network asynchronous algorithms like: leader election, building spanning trees, broadcast and convergecast problems, communication protocols [5, 6], etc. The study of algorithms with this simulator is not a complete one, but rather a preliminary one. We can say when a property is not satisfied by an I/O automaton, and we can say when it is worth trying to prove a certain property by mathematical methods, or by other methods except the simulation. The main problems regarding the simulation are:
the existence of infinitely long fair traces; the existence of an infinitely set fair traces; the actions parametrized with variables that have too many values.
References [1] Stephen J. Garland, Nancy A. Lynch, and Mandana Varizi. IOA: A Language for Specifying, Programming, and Validating Distributed Systems. MIT Laboratory for Computer Science, 1997. [2] Nancy Lynch. Distributed Algorithms. Morgan Kaufmann Publishers, San Mateo, CA, 1996. [3] Nancy Lynch, Michael Merritt, William Weihl, and Alan Fekete. Atomic Transactions. Morgan Kaufmann Publishers, 1994. [4] Nancy A. Lynch and Mark R. Tuttle. An Introduction to Input/Output Automata. CWI Quarterly, 2(3):219–246, 1989. [5] Joergen Soegaard-Andersen. Correctness of Protocols in Distributed Systems. PhD thesis, Department of Computer Science, Technical University of Denmark, Lyngby, Denmark, December 1993. ID-TR: 1993-131. [6] Butler W.Lampson. Reliable Messages and Connection Establishment. In Sape Mullender, editor, Distributed Systems. ACM Press and Addison-Wesley, chapter 10, pages 251-281, 1993.
