Finite-State Machines

A finite-state machine (FSM) or finite-state automaton is a mathematical model to design systems whose output depends on the history of their inputs and their cur-rent states, in contrast to functional systems where the output is determined by the current input only. An FSM has a number of states, and it can only be at one state at any time called its current state. Upon a triggering by an event or a condition, an FSM may change its current state. States of an FSM are shown by circles, and the transitions from one state to another by directed edges. In this sense, an FSM is a directed graph. The edges of this graph are labeled asi/o, whereiis the input in the form of an event or a condition, andois the action performed by the FSM.

A deterministic FSM is a quintuple (I, S, S0, δ, O) where

• I is a set of input signals

• Sis a finite nonempty set of states

• S0∈Sis the initial start state

• δis the state transition function such thatδ:S×I →O

• O∈Sis the set of output states

The state transition function decides on the next state using the current state and the input received. A state table shows the states as its rows and inputs as its columns, and the entries in the table are the actions or the next states. In a Moore

3.3 Finite-State Machines 27 Fig. 3.3 FSM diagram of the

Parity Checker

Table 3.1 State table for the

Parity Checker 0 1

ODD ODD EVEN

EVEN EVEN ODD

Machine type of FSM, the output is the new decided state. The Mealy Machine type of FSM provides an output and a new state as a result of being triggered.

3.3.1 Moore Machine Example: Parity Checker

As an example of Moore Machine, let us design an FSM that inputs a binary string of the form 001101010. . . and at any point, determines its state based on the number of 1s received up to that point as ODD if this number is an odd number and EVEN otherwise. This FSM called the Parity Checker has two states with the initial EVEN state in double circles as shown in Fig.3.3and based on the binary input, it may change its state. Since the output is equal to the next state this FSM decides, it is a Moore Machine.

The FSM table for the Parity Checker has states ODD and EVEN shown as rows and inputs 0 and 1, shown as columns in Table3.1.

3.3.2 Mealy Machine Example: Data Link Protocol Design

As a more detailed example of a Mealy Machine FSM, we will consider the design of a data link protocol called Stop and Wait Automatic Repeat Request (ARQ). The main responsibilities of data link in general are the flow and error control of com-munication between the sender and the receiver network nodes. In the Stop and Wait ARQ protocol, the sender has to wait for an acknowledgment from the receiver be-fore sending the next frame. There will be a single frame in transmission at a time, and to prevent the case where an acknowledgement from the receiver gets lost and the sender sends a duplicate packet that is received as a new frame by the receiver, odd and even sequence numbers are used.

28 3 The Computational Model Fig. 3.4 FSM diagrams of

the data link protocol;

(a) sender, (b) receiver

Table 3.2 State table for data

link protocol sender L3_REQ ACK NACK TIMEOUT

IDLE Act_00 NA NA NA

WTACK NA Act_11 Act_12 Act_13

Figure3.4shows the FSM of the sender and the receiver processes of the proto-col. The sender process initially is at IDLE state, and when there is a request from Layer 3 (Network Layer) to send a frame to the receiver, it prepares the frame header by inserting frame type INFO, sequence number, and error checking code there and transmits the frame after which it changes its state to WTACK to wait for a response from the receiver. In this state, it can receive either an ack frame from the receiver, which shows that the receiver has received the frame correctly, or a nack frame if the error checking at the receiver results in a negative result. If there are no replies from the receiver within a specified duration, the sender timeout expires, and it is notified by an interrupt, in which case it resends the frame. Transmission of the frame is also repeated when a nack is received.

The FSM table, Table3.2, displays the states of the sender as rows and the possi-ble inputs to the sender as columns. Any necessary action to be taken when inputj is received at statei is placed as a procedure Act_ij in this table. This method of representing the FSM provides a convenient way of coding the FSM in a C-like lan-guage. Algorithm3.3shows a possible implementation where the addresses for all actions are placed in the table initially. The sender process keeps track of its current state, and when there is an input of any kind, it simply activates the action defined by its state and the input identifier. Using FSMs with this style of coding simplifies designing and implementation of complicated network protocols and distributed al-gorithms significantly.

We will be using FSMs to model some sample distributed algorithms to aid un-derstanding them better, especially in cases where the algorithm is more compli-cated than usual.

3.4 Synchronization 29 Algorithm 3.3 Data Link Sender

1: set of states IDLE, WTACK

2: int currstate←IDLE, curr_seqno←0 3: fsm_table[2][3] ←action addresses

4: procedure Act_00(frame) send frame first time

5: frame.type←DATA set type

6: frame.seqno←curr_seqno insert sequence number

7: frame.error←calc_error(frame) calculate and insert error code 8: send(frame) to receiver

9: currstate←WTACK 10: end procedure 11:

12: procedure Act_11(frame) frame received correctly

13: currseq←(currseq+1)mod 2 increment sequence number

14: respond toL3 notify Layer 3

15: currstate←IDLE 16: end procedure 17:

18: procedure Act_12(frame) re-transmission

19: if error_count≤MAX_ERR_COUNT thenif maximum error count is not reached

20: frame.type←DATA set type

21: currseq←(currseq−1)mod 2 set seqno to the old one

22: frame.seqno←curr_seqno insert sequence number

23: frame.error←calc_error(frame) calculate and insert error code 24: send(frame) to receiver

25: else send error_report to Layer 3 report delivery error to upper layer 26: end if

27: end procedure 28:

29: while true do Sender main code

30: receive msg

31: call fsm_table[currstate][msg.type] go to action specified by currstate and msg type 32: end while

3.4 Synchronization

Synchronization can be performed at various levels of a distributed system. At hard-ware level, processors may execute in lock step, and the next step of execution is not enabled until all nodes finish their current execution. This type of synchroniza-tion requires hardware support and is possible in Single-Instrucsynchroniza-tion-Multiple-Data SIMD systems, where multiple processors perform the same computation on dif-ferent data under a single control unit. Multiple-Instruction-Multiple-Data (MIMD) systems, however, do not rely on hardware synchronization, and nodes in such sys-tems work autonomously. The MIMD syssys-tems represent distributed syssys-tems more realistically. Synchronization at network protocol level is accomplished by the

send-30 3 The Computational Model Fig. 3.5 Network layers

ing and receiving of messages to ensure correct delivery of a message to the des-tination. A typical network protocol at layer l communicates with layer l of the destination node by appending error checking codes to the message, receiving ac-knowledgements, and if there is an error, retransmission of the message is provided.

Flow control and error-free delivery are the basic operations performed at various levels. Layer 2 (Data Link Layer) provides such functions, Layer 3 (Network Layer) of the protocol stack is responsible for the routing of the messages to the destina-tion via optimal routes, and Layer 4 (Transport Layer) is responsible for delivery to the related application. The Physical Layer as the lowest layer provides all signal related functions and interface to the network. These protocol layers are displayed in Fig.3.5.

There are also possibilities of synchronization at operating system level, mid-dleware level, or the distributed application level. We will investigate these in the following sections.