Formal Specifications for Complex Systems (236368) Tutorial #10 TLA – Temporal Logic of Actions

Lossy Channel Example FIFO queue for transmission of messages from Sender to Reciever We have only lossy queues Goal: build a reliable queue using lossy ones Idea: use alternating bit protocol to ensure the messages are still delivered Assumption: there is only one message at a time we try to deliver (i.e., no “messages to be sent” queue) Can be extended to the case with messages queue (used as a module in the solution)

Alternating Bit Protocol reliable queue lossy queue SEND RCV lossy queue

no message will be sent till there is some new message AB-protocol contd. How to pass a value “d”? Initiate sBit = rBit = b; sent = “d” Sender sBit:= “!b” keeps sending “<!b,d>” on msgQ Receiver keeps sending “b” on ackQ When receiver gets “<!b,d>” on msgQ : !b  rBit => it’s a new value rcvd:=“d” rBit := !b Receiver starts sending “!b” on ackQ Eventually, Sender gets “!b” on ackQ !b = sBit => the message has been transmitted If there is a new message to transmit, “e”, sender will start sending <b, e> on msgQ (and make sBit:= “b”) no message will be sent till there is some new message

AB-protocol TLA specification (1) TLA specification consists of: Declarations part variables, constants, modules used Initiation conditions on initial states Actions description: Action  (Enabling conditions  Changes to the state  Unchanged part of the state) Example-specific definitions (macros) Requirements Temporal logic formulas; including Fairness

AB-protocol TLA specification (2) data values that can be sent. MODULE AlternatingBit Extends Naturals, Sequences Constants Data Variables ABInit 

AB-protocol TLA specification (3) //communication on the msg channel: SendNewValue(d)  ReSendMsg  RcvMsg 

AB-protocol TLA specification (4) //communication on the “ack” channel : SendAck  RcvAck  //specification of msgQ and ackQ as lossy queues LoseMsg  Lose(msgQ)  UNCHANGED ackQ LoseMsg  Lose(ackQ)  UNCHANGED msgQ //”macros” ABNext    dData: SendNewValue(d)  ReSendMsg  RcvMsg  SndAck  RcvAck  LoseMsg  LoseAck abvars  <msgQ, ackQ, sBit, sAck, rBit, sent, rcvd> Lose(q) – action of losing message from queue q; leaves unchanged sBit, sAck, rBit, sent, rcvd

AB-protocol TLA specification (5) //Requirements: //liveness condition: ABFairness   WFabvars(ReSendMsg)  WFabvars(SndAck)  SFabvars(RcvMsg)  SFabvars(RcvAck) //complete specification: ABSpec  ABInit  ⃞[ABNext]abvars  ABFairness

different from the lecture… Reliable queue different from the lecture… Goal (reminder): build a reliable queue of one element Need to show: the module we specified provides the functionality of a reliable queue Reliable queue requirements – reminder: Init  [Next]vars  WFvars (Deq) Init  (q =    in = NoMsg  out = NoMsg) vars   in, out, q  Next  Enq  Deq WFvars (Deq)  ( ENABLED [Deq] => Deqvar) Does AB-Module specification imply the requirements? “in”, “out” : in one-element queue, can be identified with sent, rcvd “q”: contains 1 or 0 elements [assumption – one message at a time…] “Enq”: in one-element queue, can be identified with SendNewMsg (first time sending the message) “Deq”: in one-element queue, can be identified with RcvMsg (first time the message is received by the receiver) Init  [Next]vars obviously holds Need to prove: WFvars (Deq) assume fairness when the module is used; prove fairness when implementation is described

Reliable queue – correctness WFvars (Deq)  ( ENABLED [Deq] => Deqvar) Need to restate in terms of our module ENABLED [Deq]  q    As seen in the lecture, q == if sBit  rBit then rq  sq else rq  tail (sq) In our case, rq = “rcvd”, sq = “sent” (1-element or empty queues) q      dData [(sBit  rBit  sent=d)  rcvd=d ]  ENABLED [Deq] = ( dData [(sBit  rBit  sent=d)  rcvd=d]) Meaning of the property to prove: if we try to send a message (sent = d), it will eventually be received (written to rcvd) If we want to send more than one message, we can perform the AB-protocol for each of the messages we want to send…

Reliable queue – correctness (2) to prove WFvars (Deq)  ( ENABLED [Deq] => Deqvar) Deqvar  RcvMsgabvar   (msgQ’ = Tail(msgQ)  rBit’ = Head(msgQ)[1]  rcvd’ = Head(msgQ)[2]  UNCHANGED <ackQ, sBit, sAck, sent>) Need to prove: ( dData [(sBit  rBit  sent=d)  rcvd=d ]) ⇒  (msgQ’ = Tail(msgQ)  rBit’ = Head(msgQ)[1] That is: [(sBit  rBit  sent=d)] ⇒  (msgQ’ =    rBit’ = sBit  rcvd’ = d  UNCHANGED <…>) Use: actions definitions; fairness properties Exists a tool for automatic proofs … If (d=rcvd), no more proof needed: RcvMsg was done => ignore this part Head(msgQ) = <sBit, d> Tail(msgQ) =   WFabvar(ReSendMsg), SFabvar(RcvMsg)