the alternating bit protocol - microsoft azure · h “mary ”;1i h derf 0i “mary ”; 1i...

TLA+ Video Course – Lecture 9, Part 2Leslie Lamport

THE ALTERNATING BIT PROTOCOL

THE PROTOCOL

This video should be viewed in conjunction with a Web page.To find that page, search the Web for TLA+ Video Course .

The TLA+ Video CourseLecture 9The Alternating Bit Protocol

In this part, we examine the Alternating Bit Protocol itself, and how itimplements the liveness property of its high-level specification.

In the process, we learn about strong fairness and some more about usingthe TLC model checker.

[ slide 2 ]

THE SAFETY SPECIFICATION

[ slide 3 ]

What the Protocol Accomplishes

Remember what the AB protocol is supposed to accomplish.

It starts with AVar and BVar having values like these, where the firstcomponent is an arbitrary data item.

A sends a data item by setting the first element of AVar to that item andcomplementing the one-bit second element.

[ slide 4 ]

What the Protocol Accomplishes

AVar :

A

〈“ ”, 1〉 BVar :

B

〈“ ”, 1〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

Remember what the AB protocol is supposed to accomplish.

It starts with AVar and BVar having values like these, where the firstcomponent is an arbitrary data item.

A sends a data item by setting the first element of AVar to that item andcomplementing the one-bit second element.

[ slide 5 ]

What the Protocol Accomplishes

AVar :

A

〈“Fred ”, 0〉 BVar :

B

〈“ ”, 1〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

Remember what the AB protocol is supposed to accomplish.

It starts with AVar and BVar having values like these, where the firstcomponent is an arbitrary data item.

A sends a data item by setting the first element of AVar to that item andcomplementing the one-bit second element.

[ slide 6 ]

What the Protocol Accomplishes

AVar :

A

〈“Fred ”, 0〉 BVar :

B

〈“Fred ”, 0〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 7 ]

What the Protocol Accomplishes

AVar :

A

〈“Mary”, 1〉 BVar :

B

〈“Fred ”, 0〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 8 ]

What the Protocol Accomplishes

AVar :

A

〈“Mary”, 1〉 BVar :

B

〈“Mary”, 1〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 9 ]

What the Protocol Accomplishes

AVar :

A

〈“Mary”, 0〉 BVar :

B

〈“Mary”, 1〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 10 ]

What the Protocol Accomplishes

AVar :

A

〈“Mary”, 0〉 BVar :

B

〈“Mary”, 0〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 11 ]

What the Protocol Accomplishes

AVar :

A

〈“Mary”, 0〉 BVar :

B

〈“Mary”, 0〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 12 ]

How the Protocol Works

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 13 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 14 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 15 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 16 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 17 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 18 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 19 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 20 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 21 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 22 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 23 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 24 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 25 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 26 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 27 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 28 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 29 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 30 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

0

So it changes BVar .

It then starts sending its new bit.

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its previous value because the message’s bit isdifferent from its bit.

[ slide 31 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

0 1

So it changes BVar .

It then starts sending its new bit.

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its previous value because the message’s bit isdifferent from its bit.

[ slide 32 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

0 1

So it changes BVar .

It then starts sending its new bit.

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its previous value because the message’s bit isdifferent from its bit.

[ slide 33 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

0 1

So it changes BVar .

It then starts sending its new bit.

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its previous value because the message’s bit isdifferent from its bit.

[ slide 34 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

0 1

So it changes BVar .

It then starts sending its new bit.

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its previous value because the message’s bit isdifferent from its bit.

[ slide 35 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 36 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Mary”, 1〉

1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 37 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Mary”, 1〉

1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 38 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Mary”, 1〉

1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 39 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 40 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1 1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 41 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1 1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 42 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1 1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 43 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1 1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 44 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Anne”, 0〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 45 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Anne”, 0〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Anne”, 0〉

1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 46 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Anne”, 0〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Anne”, 0〉

1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 47 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Anne”, 0〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Anne”, 0〉

1 1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 48 ]

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Anne”, 0〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Anne”, 0〉

1 1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 49 ]

The TLA+ Specification

Download module AB and open it in theToolbox.

Nothing new except the use of operationson sequences.

We now look at the safety part of the TLA+ specification.

It’s in module AB . Download that spec now and open it in the Toolbox.

There’s nothing new in the safety spec except that it uses the operations onsequences we examined in part one of this lecture.

[ slide 50 ]

The TLA+ Specification

Download module AB and open it in theToolbox.

Nothing new except the use of operationson sequences.

We now look at the safety part of the TLA+ specification.

It’s in module AB . Download that spec now and open it in the Toolbox.

There’s nothing new in the safety spec except that it uses the operations onsequences we examined in part one of this lecture.

[ slide 51 ]

The TLA+ Specification

Download module AB and open it in theToolbox.

Nothing new except the use of operationson sequences.

We now look at the safety part of the TLA+ specification.

It’s in module AB . Download that spec now and open it in the Toolbox.

There’s nothing new in the safety spec except that it uses the operations onsequences we examined in part one of this lecture.

[ slide 52 ]

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 53 ]

Imports operators on sequences.

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 54 ]

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 55 ]

Same as in ABSpec.

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 56 ]

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 57 ]

Sequence seq with itsi th element removed.

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 58 ]

And this is the definition we saw before.

[ slide 59 ]

AVar and BVar are the same variables as in ABSpec, while A to B andB to A are additional variables that represent the message channels.

As usual, we define vars to be the tuple of all variables.

Next is the type-correctness invariant.

The possible values of AVar and BVar are the same as in ABSpec.

[ slide 60 ]

AVar and BVar are the same variables as in ABSpec, while A to B andB to A are additional variables that represent the message channels.

As usual, we define vars to be the tuple of all variables.

Next is the type-correctness invariant.

The possible values of AVar and BVar are the same as in ABSpec.

[ slide 61 ]

AVar and BVar are the same variables as in ABSpec, while A to B andB to A are additional variables that represent the message channels.

As usual, we define vars to be the tuple of all variables.

Next is the type-correctness invariant.

The possible values of AVar and BVar are the same as in ABSpec.

[ slide 62 ]

AVar and BVar are the same variables as in ABSpec, while A to B andB to A are additional variables that represent the message channels.

As usual, we define vars to be the tuple of all variables.

Next is the type-correctness invariant.

The possible values of AVar and BVar are the same as in ABSpec.

[ slide 63 ]

Same as in ABSpec.

AVar and BVar are the same variables as in ABSpec, while A to B andB to A are additional variables that represent the message channels.

As usual, we define vars to be the tuple of all variables.

Next is the type-correctness invariant.

The possible values of AVar and BVar are the same as in ABSpec.

[ slide 64 ]

AtoB is an element of the set of all sequences of values that A can send.

A sends a message by appending it to the end of AtoB .

B receives the message at the head of AtoB .

[ slide 65 ]

The set of sequences of

AtoB is an element of the set of all sequences of values that A can send.

A sends a message by appending it to the end of AtoB .

B receives the message at the head of AtoB .

[ slide 66 ]

The set of sequences of values A can send.

AtoB is an element of the set of all sequences of values that A can send.

A sends a message by appending it to the end of AtoB .

B receives the message at the head of AtoB .

[ slide 67 ]

A sends a message by appending it to the end of AtoB .B receives the message at the head of AtoB .

AtoB is an element of the set of all sequences of values that A can send.

A sends a message by appending it to the end of AtoB .

B receives the message at the head of AtoB .

[ slide 68 ]

A sends a message by appending it to the end of AtoB .B receives the message at the head of AtoB .

AtoB is an element of the set of all sequences of values that A can send.

A sends a message by appending it to the end of AtoB .

B receives the message at the head of AtoB .

[ slide 69 ]

The set of sequences of bits

And similarly, the value of BtoA is always a sequence of bits.

AVar and BVar have the same initial values as in ABSpec.

And the channels initially equal the empty sequence.[ slide 70 ]

Same as in ABSpec

And similarly, the value of BtoA is always a sequence of bits.

AVar and BVar have the same initial values as in ABSpec.

And the channels initially equal the empty sequence.[ slide 71 ]

Channels are empty.

And similarly, the value of BtoA is always a sequence of bits.

AVar and BVar have the same initial values as in ABSpec.

And the channels initially equal the empty sequence.[ slide 72 ]

And similarly, the value of BtoA is always a sequence of bits.

AVar and BVar have the same initial values as in ABSpec.

And the channels initially equal the empty sequence.[ slide 73 ]

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

The next-state action is the disjunction of five subactions whose definitionscome next.

A-send is defined to be the action of A sending a message.

A-receive is defined to be the action of A receiving a message.

[ slide 74 ]

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

The next-state action is the disjunction of five subactions whose definitionscome next.

A-send is defined to be the action of A sending a message.

A-receive is defined to be the action of A receiving a message.

[ slide 75 ]

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

The next-state action is the disjunction of five subactions whose definitionscome next.

A-send is defined to be the action of A sending a message.

A-receive is defined to be the action of A receiving a message.

[ slide 76 ]

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

The next-state action is the disjunction of five subactions whose definitionscome next.

A-send is defined to be the action of A sending a message.

A-receive is defined to be the action of A receiving a message.

[ slide 77 ]

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

The next-state action is the disjunction of five subactions whose definitionscome next.

A-send is defined to be the action of A sending a message.

A-receive is defined to be the action of A receiving a message.

[ slide 78 ]

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 79 ]

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 80 ]

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 81 ]

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 82 ]

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 83 ]

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 84 ]

The definition of A-send is simple.It appends the value of AVar to the end of the sequence A-to-BAnd leaves all the other variables unchanged.

The action is always enabled.

The action of A receiving a message from B

[ slide 85 ]

The definition of A-send is simple.It appends the value of AVar to the end of the sequence A-to-BAnd leaves all the other variables unchanged.

The action is always enabled.

The action of A receiving a message from B

[ slide 86 ]

The definition of A-send is simple.It appends the value of AVar to the end of the sequence A-to-BAnd leaves all the other variables unchanged.

The action is always enabled.

The action of A receiving a message from B

[ slide 87 ]

The definition of A-send is simple.It appends the value of AVar to the end of the sequence A-to-BAnd leaves all the other variables unchanged.

The action is always enabled.

The action of A receiving a message from B

[ slide 88 ]

is enabled only when the sequence B -to-A of messages from B is not empty.

If the bit at the head of B -to-A equals AVar ’s bit, so B is acknowledgingAVar ’s current value,then the new value of AVar is set just like in the A action of ABSpec: to a pairwhose first element is a non-deterministically chosen element of Data,[ slide 89 ]

is enabled only when the sequence B -to-A of messages from B is not empty.

If the bit at the head of B -to-A equals AVar ’s bit, so B is acknowledgingAVar ’s current value,then the new value of AVar is set just like in the A action of ABSpec: to a pairwhose first element is a non-deterministically chosen element of Data,[ slide 90 ]

is enabled only when the sequence B -to-A of messages from B is not empty.

If the bit at the head of B -to-A equals AVar ’s bit, so B is acknowledgingAVar ’s current value,then the new value of AVar is set just like in the A action of ABSpec: to a pairwhose first element is a non-deterministically chosen element of Data,[ slide 91 ]

is enabled only when the sequence B -to-A of messages from B is not empty.

If the bit at the head of B -to-A equals AVar ’s bit, so B is acknowledgingAVar ’s current value,then the new value of AVar is set just like in the A action of ABSpec: to a pairwhose first element is a non-deterministically chosen element of Data,[ slide 92 ]

and whose second element is the complement of the current value of AVar ’sbit.

Otherwise, AVar is unchanged.

And the message A is receiving, which is at the head of the sequenceB -to-A, is removed from B -to-A.

[ slide 93 ]

and whose second element is the complement of the current value of AVar ’sbit.

Otherwise, AVar is unchanged.

And the message A is receiving, which is at the head of the sequenceB -to-A, is removed from B -to-A.

[ slide 94 ]

and whose second element is the complement of the current value of AVar ’sbit.

Otherwise, AVar is unchanged.

And the message A is receiving, which is at the head of the sequenceB -to-A, is removed from B -to-A.

[ slide 95 ]

The definitions of BSnd and BRcv are similar; you can read them yourself.

[ slide 96 ]

Next comes the definition of Lose Message.

It removes a message from AtoB or BtoA and leaves AVar and BVar

unchanged.

The formula that describes removing a message from AtoB asserts that forsome i between 1 and the length of the sequence AtoB

[ slide 97 ]

Remove a message from AtoB .

Remove a message from BtoA .

Next comes the definition of Lose Message.

It removes a message from AtoB or BtoA and leaves AVar and BVar

unchanged.

The formula that describes removing a message from AtoB asserts that forsome i between 1 and the length of the sequence AtoB

[ slide 98 ]

Remove a message from BtoA .

Next comes the definition of Lose Message.

It removes a message from AtoB or BtoA and leaves AVar and BVar

unchanged.

The formula that describes removing a message from AtoB asserts that forsome i between 1 and the length of the sequence AtoB

[ slide 99 ]

Remove a message from BtoA .

the new value of AtoB is the sequence obtained by removing the i th elementfrom the current value of AtoB .

And BtoA is unchanged.

The formula that describes removing a message from BtoA

is similar.

[ slide 100 ]

Remove a message from BtoA .

the new value of AtoB is the sequence obtained by removing the i th elementfrom the current value of AtoB .

And BtoA is unchanged.

The formula that describes removing a message from BtoA

is similar.

[ slide 101 ]

Remove a message from BtoA .

the new value of AtoB is the sequence obtained by removing the i th elementfrom the current value of AtoB .

And BtoA is unchanged.

The formula that describes removing a message from BtoA

is similar.

[ slide 102 ]

the new value of AtoB is the sequence obtained by removing the i th elementfrom the current value of AtoB .

And BtoA is unchanged.

The formula that describes removing a message from BtoA

is similar.

[ slide 103 ]

Then comes the definition of Next

and the standard safety specification.

[ slide 104 ]

Then comes the definition of Next

and the standard safety specification.

[ slide 105 ]

CHECKING SAFETY

[ slide 106 ]

Create a new model with the default specification Spec,

letting Data be a small set of model values.

[ slide 107 ]

Create a new model with the default specification Spec,

letting Data be a small set of model values.

[ slide 108 ]

But don’t run TLC yet.

Have TLC check that TypeOK is an invariant.

But don’t run it yet.

[ slide 109 ]

But don’t run TLC yet.

Have TLC check that TypeOK is an invariant.

But don’t run it yet.

[ slide 110 ]

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

A and B can keep sending messages faster than they get lost or received.

So there’s no limit to how long the sequences AtoB and BtoA can be.

The specification allows infinitely many reachable states, and since TLC triesto compute all reachable states, it will run forever.

[ slide 111 ]

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

A and B can keep sending messages faster than they get lost or received.

So there’s no limit to how long the sequences AtoB and BtoA can be.

The specification allows infinitely many reachable states, and since TLC triesto compute all reachable states, it will run forever.

[ slide 112 ]

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

A and B can keep sending messages faster than they get lost or received.

So there’s no limit to how long the sequences AtoB and BtoA can be.

The specification allows infinitely many reachable states, and since TLC triesto compute all reachable states, it will run forever.

[ slide 113 ]

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

A and B can keep sending messages faster than they get lost or received.

So there’s no limit to how long the sequences AtoB and BtoA can be.

The specification allows infinitely many reachable states, and since TLC triesto compute all reachable states, it will run forever.

[ slide 114 ]

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

We could change the spec to limit the lengths of AtoB and BtoA, but weshouldn’t have to change the spec to model check it.

[ slide 115 ]

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

We could change the spec to limit the lengths of AtoB and BtoA, but weshouldn’t have to change the spec to model check it.

[ slide 116 ]

We can tell TLC to examine only stateswhere AtoB and BtoA are not too long.

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

Here’s how we can tell TLC to examine only states in which AtoB and BtoA

aren’t too long.

On the model’s advanced options page, go to the state constraint section.

[ slide 117 ]

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

Here’s how we can tell TLC to examine only states in which AtoB and BtoA

aren’t too long.

On the model’s advanced options page, go to the state constraint section.

[ slide 118 ]

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

Here’s how we can tell TLC to examine only states in which AtoB and BtoA

aren’t too long.

On the model’s advanced options page, go to the state constraint section.

[ slide 119 ]

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

For example, you can tell TLC to examine only states in which the lengths ofAtoB and BtoA are at most 3,by entering this state formula.

To understand exactly what this does

[ slide 120 ]

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

For example, you can tell TLC to examine only states in which the lengths ofAtoB and BtoA are at most 3,by entering this state formula.

To understand exactly what this does

[ slide 121 ]

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

For example, you can tell TLC to examine only states in which the lengths ofAtoB and BtoA are at most 3,by entering this state formula.

To understand exactly what this does

[ slide 122 ]

How TLC Computes Reachable States

you need to understand how TLC computes reachable states when it has nostate constraint.

Starting from the set of initial states. It chooses one. and computes allpossible next states from that state.

And so on, until it has explored all reachable states.

[ slide 123 ]

How TLC Computes Reachable States

i i

you need to understand how TLC computes reachable states when it has nostate constraint.

Starting from the set of initial states. It chooses one. and computes allpossible next states from that state.

And so on, until it has explored all reachable states.

[ slide 124 ]

How TLC Computes Reachable States

i ir

you need to understand how TLC computes reachable states when it has nostate constraint.

Starting from the set of initial states. It chooses one. and computes allpossible next states from that state.

And so on, until it has explored all reachable states.

[ slide 125 ]

How TLC Computes Reachable States

i iri i

iiK�

R�

you need to understand how TLC computes reachable states when it has nostate constraint.

Starting from the set of initial states. It chooses one. and computes allpossible next states from that state.

And so on, until it has explored all reachable states.

[ slide 126 ]

How TLC Computes Reachable States

ir ii i

iiK�

R�

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 127 ]

How TLC Computes Reachable States

ir ii i

iiii �

IK�

R�

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 128 ]

How TLC Computes Reachable States

i iir i

iiii �

IK�

R�

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 129 ]

How TLC Computes Reachable States

i iir i

iiiii i i i

�

IK�

R�

Y M � 1

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 130 ]

How TLC Computes Reachable States

i ii ir

iiiii i i i

�

IK�

R�

Y M � 1

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 131 ]

How TLC Computes Reachable States

i ii ir

iiiii i i i i

�

IK�

R�

Y M � 1�1

�

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 132 ]

How TLC Computes Reachable States

i ii i

iriiii i i i i

�

IK�

R�

Y M � 1�1

�

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 133 ]

How TLC Computes Reachable States

i ii i

iriiii i i i i

iii

�

IK�

R�

Y M � 1�1

�

�

j?

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 134 ]

How TLC Computes Reachable States

i ii i

iiriii i i i i

iii

�

IK�

R�

Y M � 1�1

�

�

j?

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 135 ]

How TLC Computes Reachable States

i ii i

iiriii i i i i

iiiii

�

IK�

R�

Y M � 1�1

�

�

j?

?�

1

j

1

j

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 136 ]

How TLC Computes Reachable States

i ii i

iiirii i i i i

iiiii

�

IK�

R�

Y M � 1�1

�

�

j?

?�

1

j

1

j

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 137 ]

How TLC Uses a Constraint

Now here’s how TLC computes reachable states when it has a stateconstraint.

Starting from the set of initial states. It chooses one and then checks if thestate satisfies the constraint.

Let’s suppose it does.

[ slide 138 ]

How TLC Uses a Constraint

i i

Now here’s how TLC computes reachable states when it has a stateconstraint.

Starting from the set of initial states. It chooses one and then checks if thestate satisfies the constraint.

Let’s suppose it does.

[ slide 139 ]

How TLC Uses a Constraint

i ir

Now here’s how TLC computes reachable states when it has a stateconstraint.

Starting from the set of initial states. It chooses one and then checks if thestate satisfies the constraint.

Let’s suppose it does.

[ slide 140 ]

How TLC Uses a Constraint

i xi

Now here’s how TLC computes reachable states when it has a stateconstraint.

Starting from the set of initial states. It chooses one and then checks if thestate satisfies the constraint.

Let’s suppose it does.

[ slide 141 ]

How TLC Uses a Constraint

i xii i

iiK�

R�

As before, TLC then computes all possible next states from that state

and chooses another state to explore. It checks if that state satisfies theconstraint Again, let’s suppose it does.

[ slide 142 ]

How TLC Uses a Constraint

ir ii i

iiK�

R�

As before, TLC then computes all possible next states from that state

and chooses another state to explore. It checks if that state satisfies theconstraint Again, let’s suppose it does.

[ slide 143 ]

How TLC Uses a Constraint

xi ii i

iiK�

R�

As before, TLC then computes all possible next states from that state

and chooses another state to explore. It checks if that state satisfies theconstraint Again, let’s suppose it does.

[ slide 144 ]

How TLC Uses a Constraint

xi ii i

iiii �

IK�

R�

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 145 ]

How TLC Uses a Constraint

i iir i

iiii �

IK�

R�

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 146 ]

How TLC Uses a Constraint

i ixi i

iiii �

IK�

R�

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 147 ]

How TLC Uses a Constraint

i ixi i

iiiii i i i

�

IK�

R�

Y M � 1

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 148 ]

How TLC Uses a Constraint

i ii ir

iiiii i i i

�

IK�

R�

Y M � 1

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 149 ]

How TLC Uses a Constraint

i ii ix×

iiiii i i i

�

IK�

R�

Y M � 1

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 150 ]

How TLC Uses a Constraint

i ii i

iriiii i i i

�

IK�

R�

Y M � 1

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 151 ]

How TLC Uses a Constraint

i ii i

xiiiii i i i

�

IK�

R�

Y M � 1

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 152 ]

How TLC Uses a Constraint

i ii i

xiiiii i i i

iii

�

IK�

R�

Y M � 1

�

j?

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 153 ]

How TLC Uses a Constraint

i ii i

iiriii i i i

iii

�

IK�

R�

Y M � 1

�

j?

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 154 ]

How TLC Uses a Constraint

i ii i

ix×iiii i i i

iii

�

IK�

R�

Y M � 1

�

j?

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 155 ]

How TLC Uses a Constraint

i ii i

iiirii i i i

iii

�

IK�

R�

Y M � 1

�

j?

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 156 ]

You can now run TLC on your model.

You can now run TLC on your model.

The alternating bit protocol should implement its high-level specification,which means that formula Spec of module AB should imply formula Spec ofmodule ABSpec.

This should be a theorem of module AB that TLC can check, but how canwe write it?

[ slide 157 ]

The AB protocol should implement its high-levelspecification, so formula Spec of module AB

should imply formula Spec of module ABSpec .

This should be a theorem of module AB ,but how can we write it?

INSTANCE ABSpec

is illegal in module AB because it imports definitions ofSpec, . . . , which are already defined in AB .

You can now run TLC on your model.

The alternating bit protocol should implement its high-level specification,which means that formula Spec of module AB should imply formula Spec ofmodule ABSpec.

This should be a theorem of module AB that TLC can check, but how canwe write it?

[ slide 158 ]

The AB protocol should implement its high-levelspecification, so formula Spec of module AB

should imply formula Spec of module ABSpec .

This should be a theorem of module AB ,but how can we write it?

INSTANCE ABSpec

is illegal in module AB because it imports definitions ofSpec, . . . , which are already defined in AB .

You can now run TLC on your model.

The alternating bit protocol should implement its high-level specification,which means that formula Spec of module AB should imply formula Spec ofmodule ABSpec.

This should be a theorem of module AB that TLC can check, but how canwe write it?

[ slide 159 ]

The AB protocol should implement its high-levelspecification, so formula Spec of module AB

should imply formula Spec of module ABSpec .

This should be a theorem of module AB ,but how can we write it?

INSTANCE ABSpec

is illegal in module AB because it imports definitions ofSpec, . . . , which are already defined in AB .

You can now run TLC on your model.

The alternating bit protocol should implement its high-level specification,which means that formula Spec of module AB should imply formula Spec ofmodule ABSpec.

This should be a theorem of module AB that TLC can check, but how canwe write it?

[ slide 160 ]

The AB protocol should implement its high-levelspecification, so formula Spec of module AB

should imply formula Spec of module ABSpec .

This should be a theorem of module AB ,but how can we write it?

INSTANCE ABSpec

is illegal in module AB because it imports definitions ofSpec, . . . , which are already defined in AB .

You can now run TLC on your model.

The alternating bit protocol should implement its high-level specification,which means that formula Spec of module AB should imply formula Spec ofmodule ABSpec.

This should be a theorem of module AB that TLC can check, but how canwe write it?

[ slide 161 ]

The AB protocol should implement its high-levelspecification, so formula Spec of module AB

should imply formula Spec of module ABSpec .

This should be a theorem of module AB ,but how can we write it?

INSTANCE ABSpec

is illegal in module AB because it imports definitions ofSpec, . . . , which are already defined in AB .

The statement “INSTANCE ABSpec” is illegal in module AB because itimports definitions of identifiers like Spec, which are already defined in AB .

[ slide 162 ]

ABS∆= INSTANCE ABSpec

Imports definitions of Spec, . . . from ABSpec

renamed as ABS !Spec, . . . .

THEOREM Spec ⇒ ABS !Spec

Module AB contains the statement: A-B-S is defined to equal thisinstantiation.

This statement imports into module AB all the definitions, such as that ofSpec, from module ABSpec except renaming them by prefacing their nameswith A-B-S-bang.

[ slide 163 ]

ABS∆= INSTANCE ABSpec

Imports definitions of Spec, . . . from ABSpec

renamed as ABS !Spec, . . . .

THEOREM Spec ⇒ ABS !Spec

Module AB contains the statement: A-B-S is defined to equal thisinstantiation.

This statement imports into module AB all the definitions, such as that ofSpec, from module ABSpec except renaming them by prefacing their nameswith A-B-S-bang.

[ slide 164 ]

ABS∆= INSTANCE ABSpec

Imports definitions of Spec, . . . from ABSpec

renamed as ABS !Spec, . . . .

THEOREM Spec ⇒ ABS !Spec

Module AB contains the statement: A-B-S is defined to equal thisinstantiation.

This statement imports into module AB all the definitions, such as that ofSpec, from module ABSpec except renaming them by prefacing their nameswith A-B-S-bang.

[ slide 165 ]

ABS∆= INSTANCE ABSpec

Imports definitions of Spec, . . . from ABSpec

renamed as ABS !Spec, . . . .

THEOREM Spec ⇒ ABS !Spec

This theorem states that the safety specification of the alternating bit protocolimplements its high-level safety specification from module ABSpec.

TLC will verify it by checking that specification Spec satisfies the temporalproperty A-B-S bang spec .

[ slide 166 ]

ABS∆= INSTANCE ABSpec

Imports definitions of Spec, . . . from ABSpec

renamed as ABS !Spec, . . . .

THEOREM Spec ⇒ ABS !Spec

This theorem states that the safety specification of the alternating bit protocolimplements its high-level safety specification from module ABSpec.

TLC will verify it by checking that specification Spec satisfies the temporalproperty A-B-S bang spec .

[ slide 167 ]

LIVENESS

[ slide 168 ]

The complete AB protocol specification should be

The complete protocol specification should be a formula we’ll call FairSpecthat’s the conjunction of the safety spec and one or more fairness properties.

These fairness properties should imply that messages keep getting sent andreceived.

[ slide 169 ]

The complete AB protocol specification should be

FairSpec∆= Spec ∧ fairness properties

The complete protocol specification should be a formula we’ll call FairSpecthat’s the conjunction of the safety spec and one or more fairness properties.

These fairness properties should imply that messages keep getting sent andreceived.

[ slide 170 ]

FairSpec∆= Spec ∧ fairness properties

Should imply that messageskeep getting sent and received.

The complete protocol specification should be a formula we’ll call FairSpecthat’s the conjunction of the safety spec and one or more fairness properties.

These fairness properties should imply that messages keep getting sent andreceived.

[ slide 171 ]

FairSpec∆= Spec ∧ fairness properties

Should imply that messageskeep getting sent and received.

THEOREM FairSpec ⇒ ABS !FairSpec

Which means that this theorem should be true.

[ slide 172 ]

FairSpec∆= Spec ∧ fairness properties

Which means that this theorem should be true.

[ slide 173 ]

FairSpec∆= Spec ∧ WFvars(Next)

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 174 ]

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 175 ]

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 176 ]

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

11

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 177 ]

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

111

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 178 ]

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1111

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 179 ]

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

11111

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 180 ]

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

111111

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 181 ]

FairSpec∆= Spec ∧ fairness properties

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 182 ]

FairSpec∆= Spec ∧ fairness properties

Next∆= ASnd ∨ ARcv ∨ BSnd ∨ BRcv ∨ LoseMsg

Remember the definition of the next-state action.

We need separate fairness requirements on these four subactions, to makesure that each of them keeps being executed.

We don’t want any fairness requirement on the Lose-Message actionbecause we don’t want to require that messages have to be lost.

So, let’s try weak fairness of these actions.

[ slide 183 ]

FairSpec∆= Spec ∧ fairness properties

Next∆= ASnd ∨ ARcv ∨ BSnd ∨ BRcv ∨ LoseMsg

Remember the definition of the next-state action.

We need separate fairness requirements on these four subactions, to makesure that each of them keeps being executed.

We don’t want any fairness requirement on the Lose-Message actionbecause we don’t want to require that messages have to be lost.

So, let’s try weak fairness of these actions.

[ slide 184 ]

FairSpec∆= Spec ∧ fairness properties

Next∆= ASnd ∨ ARcv ∨ BSnd ∨ BRcv ∨ LoseMsg

Remember the definition of the next-state action.

We need separate fairness requirements on these four subactions, to makesure that each of them keeps being executed.

We don’t want any fairness requirement on the Lose-Message actionbecause we don’t want to require that messages have to be lost.

So, let’s try weak fairness of these actions.

[ slide 185 ]

FairSpec∆= Spec ∧ fairness properties

Next∆= ASnd ∨ ARcv ∨ BSnd ∨ BRcv ∨ LoseMsg

Remember the definition of the next-state action.

We need separate fairness requirements on these four subactions, to makesure that each of them keeps being executed.

We don’t want any fairness requirement on the Lose-Message actionbecause we don’t want to require that messages have to be lost.

So, let’s try weak fairness of these actions.

[ slide 186 ]

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Module AB contains this definition.

Change it by replacing these two ess-es by double-ewes.

This is a plausible specification, so let’s check if it satisfies this theorem.

[ slide 187 ]

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Module AB contains this definition.

Change it by replacing these two ess-es by double-ewes.

This is a plausible specification, so let’s check if it satisfies this theorem.

[ slide 188 ]

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Module AB contains this definition.

Change it by replacing these two ess-es by double-ewes.

This is a plausible specification, so let’s check if it satisfies this theorem.

[ slide 189 ]

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

THEOREM FairSpec ⇒ ABS !FairSpec

Module AB contains this definition.

Change it by replacing these two ess-es by double-ewes.

This is a plausible specification, so let’s check if it satisfies this theorem.

[ slide 190 ]

Clone your model (removing any symmetry set).

Modify the specification and property to check.

Make a clone of the model you used before (removing any symmetry set).

In the clone, modify the specification and property to check by replacing Spec

with FairSpec.

[ slide 191 ]

Clone your model (removing any symmetry set).

Modify the specification and property to check.

Make a clone of the model you used before (removing any symmetry set).

In the clone, modify the specification and property to check by replacing Spec

with FairSpec.

[ slide 192 ]

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

[ slide 193 ]

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

[ slide 194 ]

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

[ slide 195 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 196 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 197 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 198 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 199 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 200 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 201 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 202 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 203 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 204 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 205 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 206 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 207 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 208 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

WFvars(ASnd) and WFvars(BSnd) are truebecause ASnd and BSnd steps keep occurring.

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 209 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

What about WFvars(ARcv)?

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 210 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)?

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 211 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 212 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 213 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 214 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 215 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 216 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 217 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 218 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 219 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 220 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 221 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 222 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 223 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)?

So weak fairness of A-receive is true on this behavior

because A-receive keeps getting disabled after it’s enabled, and it’s nevercontinuously enabled.

Weak fairness of B-receive is also true on this behavior for the same reason.

[ slide 224 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)? True

So weak fairness of A-receive is true on this behavior

because A-receive keeps getting disabled after it’s enabled, and it’s nevercontinuously enabled.

Weak fairness of B-receive is also true on this behavior for the same reason.

[ slide 225 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)? Truebecause ARcv never continuously enabled.

So weak fairness of A-receive is true on this behavior

because A-receive keeps getting disabled after it’s enabled, and it’s nevercontinuously enabled.

Weak fairness of B-receive is also true on this behavior for the same reason.

[ slide 226 ]

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

WFvars(BRcv) is also true.

So weak fairness of A-receive is true on this behavior

because A-receive keeps getting disabled after it’s enabled, and it’s nevercontinuously enabled.

Weak fairness of B-receive is also true on this behavior for the same reason.

[ slide 227 ]

The behavior satisfies FairSpec , defined by:

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

but doesn’t satisfy ABS !FairSpec .

((((((((

(((((((

((((

(((((((

(((((((

(((((hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhhTHEOREM FairSpec ⇒ ABS !FairSpec

The behavior satisfies FairSpec , when it’s defined like this.

but it doesn’t satisfy the high level fair spec in module ABSpec because novalues are ever sent from A to B.

So this theorem is not true.

[ slide 228 ]

The behavior satisfies FairSpec , defined by:

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

but doesn’t satisfy ABS !FairSpec .

((((((((

(((((((

((((

(((((((

(((((((

(((((hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhhTHEOREM FairSpec ⇒ ABS !FairSpec

The behavior satisfies FairSpec , when it’s defined like this.

but it doesn’t satisfy the high level fair spec in module ABSpec because novalues are ever sent from A to B.

So this theorem is not true.

[ slide 229 ]

The behavior satisfies FairSpec , defined by:

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

but doesn’t satisfy ABS !FairSpec .

((((((((

(((((((

((((

(((((((

(((((((

(((((hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhhTHEOREM FairSpec ⇒ ABS !FairSpec

The behavior satisfies FairSpec , when it’s defined like this.

but it doesn’t satisfy the high level fair spec in module ABSpec because novalues are ever sent from A to B.

So this theorem is not true.

[ slide 230 ]

The behavior satisfies FairSpec , defined by:

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

but doesn’t satisfy ABS !FairSpec .

((((((((

(((((((

((((

(((((((

(((((((

(((((hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhhTHEOREM FairSpec ⇒ ABS !FairSpec

The behavior satisfies FairSpec , when it’s defined like this.

but it doesn’t satisfy the high level fair spec in module ABSpec because novalues are ever sent from A to B.

So this theorem is not true.

[ slide 231 ]

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Don’t imply ARcv or BRcv steps ever occur,because actions keep getting disabled.

The problem is that

these weak fairness conditions don’t imply that any A-receive or B-recievesteps ever occur, because those actions keep getting disabled.

[ slide 232 ]

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Don’t imply ARcv or BRcv steps ever occur,because actions keep getting disabled.

The problem is that

these weak fairness conditions don’t imply that any A-receive or B-recievesteps ever occur, because those actions keep getting disabled.

[ slide 233 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42 → s43 → s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

Remember that weak fairness of A means if A ever remains continuouslyenabled, then an A step must eventually occur.

Strong fairness of A means that if A ever is repeatedly enabled, then an A

step must eventually occur.

[ slide 234 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42 → s43 → s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

Remember that weak fairness of A means if A ever remains continuouslyenabled, then an A step must eventually occur.

Strong fairness of A means that if A ever is repeatedly enabled, then an A

step must eventually occur.

[ slide 235 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42 → s43 → s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 236 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42 → s43 → s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 237 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43 → s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 238 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 239 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45 → s46 → s47 → s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 240 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46 → s47 → s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 241 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47 → s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 242 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 243 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48

false→ s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 244 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48

false→ s49

false→ s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 245 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48

false→ s49

false→ s50

true→ · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 246 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48

false→ s49

false→ s50

true→ · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

where it keeps being re-enabled after it becomes disabled.

Then an A step must eventually occur.

An equivalent way of saying this is that A cannot be repeatedly enabledforever without another A step occurring.

[ slide 247 ]

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48

false→ s49

false→ s50

true→ · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

where it keeps being re-enabled after it becomes disabled.

Then an A step must eventually occur.

An equivalent way of saying this is that A cannot be repeatedly enabledforever without another A step occurring.

[ slide 248 ]

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

We need to change the definition of FairSpec to what it was originallychanging these weak fairness conditions to strong fairness.

Since the B -send action is always enabled, weak fairness of B -send impliesthat B keeps sending messages. This keeps enabling A-receive which, bystrong fairness implies that A-receive steps must eventually occur to receivethose messages — even if Lose-message actions keep disabling A-receive.

[ slide 249 ]

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

We need to change the definition of FairSpec to what it was originallychanging these weak fairness conditions to strong fairness.

Since the B -send action is always enabled, weak fairness of B -send impliesthat B keeps sending messages. This keeps enabling A-receive which, bystrong fairness implies that A-receive steps must eventually occur to receivethose messages — even if Lose-message actions keep disabling A-receive.

[ slide 250 ]

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

We need to change the definition of FairSpec to what it was originallychanging these weak fairness conditions to strong fairness.

Since the B -send action is always enabled, weak fairness of B -send impliesthat B keeps sending messages. This keeps enabling A-receive which, bystrong fairness implies that A-receive steps must eventually occur to receivethose messages — even if Lose-message actions keep disabling A-receive.

[ slide 251 ]

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

B must keep sending messageswhich implies A must eventuallyreceive those messages.

We need to change the definition of FairSpec to what it was originallychanging these weak fairness conditions to strong fairness.

Since the B -send action is always enabled, weak fairness of B -send impliesthat B keeps sending messages. This keeps enabling A-receive which, bystrong fairness implies that A-receive steps must eventually occur to receivethose messages — even if Lose-message actions keep disabling A-receive.

[ slide 252 ]

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

B must keep sending messageswhich implies A must eventuallyreceive those messages.

We need to change the definition of FairSpec to what it was originallychanging these weak fairness conditions to strong fairness.

Since the B -send action is always enabled, weak fairness of B -send impliesthat B keeps sending messages. This keeps enabling A-receive which, bystrong fairness implies that A-receive steps must eventually occur to receivethose messages — even if Lose-message actions keep disabling A-receive.

[ slide 253 ]

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

A must keep sending messagesthat B must eventually receive.

Similarly, A must keep sending messages that B must eventually receive.

With this definition, the theorem is true.

You can change the definition of FairSpec in the module and rerun the model,and TLC will now find no error.[ slide 254 ]

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

A must keep sending messagesthat B must eventually receive.

Similarly, A must keep sending messages that B must eventually receive.

With this definition, the theorem is true.

You can change the definition of FairSpec in the module and rerun the model,and TLC will now find no error.[ slide 255 ]

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Similarly, A must keep sending messages that B must eventually receive.

With this definition, the theorem is true.

You can change the definition of FairSpec in the module and rerun the model,and TLC will now find no error.[ slide 256 ]

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

THEOREM FairSpec ⇒ ABS !FairSpec

TLC will now find no error.

Similarly, A must keep sending messages that B must eventually receive.

With this definition, the theorem is true.

You can change the definition of FairSpec in the module and rerun the model,and TLC will now find no error.[ slide 257 ]

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

THEOREM FairSpec ⇒ ABS !FairSpec

TLC will now find no error.

Similarly, A must keep sending messages that B must eventually receive.

With this definition, the theorem is true.

You can change the definition of FairSpec in the module and rerun the model,and TLC will now find no error.[ slide 258 ]

What Good is Liveness?

What good is knowing that something eventuallyhappens

How can we ensure strong fairness of the ARcv and BRcv

actions? Or ever know that it’s not satisfied?

What Good is Liveness?

What good is knowing that something eventually happens?If it could be a million years from now when it happens.

[ slide 259 ]

What Good is Liveness?

What good is knowing that something eventuallyhappens?

How can we ensure strong fairness of the ARcv and BRcv

actions? Or ever know that it’s not satisfied?

What Good is Liveness?

What good is knowing that something eventually happens?If it could be a million years from now when it happens.

[ slide 260 ]

What Good is Liveness?

What good is knowing that something eventuallyhappens – if it could be 106 years from now?

How can we ensure strong fairness of the ARcv and BRcv

actions? Or ever know that it’s not satisfied?

What Good is Liveness?

What good is knowing that something eventually happens?If it could be a million years from now when it happens.

[ slide 261 ]

What Good is Liveness?

What good is knowing that something eventuallyhappens – if it could be 106 years from now?

How can we ensure strong fairness of the ARcv and BRcv

actions? Or ever know that it’s not satisfied?

How can we ensure strong fairness of the ARcv and BRcv actions?Or ever know that it’s not satisfied? Since it would take forever to be sure thatit’s not.

[ slide 262 ]

What Good is Liveness?

What good is knowing that something eventuallyhappens – if it could be 106 years from now?

How can we ensure strong fairness of the ARcv and BRcv

actions? Or ever know that it’s not satisfied?

How can we ensure strong fairness of the ARcv and BRcv actions?Or ever know that it’s not satisfied? Since it would take forever to be sure thatit’s not.

[ slide 263 ]

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

A specification is an abstraction.

It’s a compromise between our desires for accuracy and simplicity.

We’d like to require that a message is received within 4.7 milliseconds ofwhen it’s sent.

[ slide 264 ]

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

A specification is an abstraction.

It’s a compromise between our desires for accuracy and simplicity.

We’d like to require that a message is received within 4.7 milliseconds ofwhen it’s sent.

[ slide 265 ]

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

A specification is an abstraction.

It’s a compromise between our desires for accuracy and simplicity.

We’d like to require that a message is received within 4.7 milliseconds ofwhen it’s sent.

[ slide 266 ]

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

But that would require specifying:

How long it can take a message to be received.

How often messages can be lost.

And how frequently messages are retransmitted.

[ slide 267 ]

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

But that would require specifying:

How long it can take a message to be received.

How often messages can be lost.

And how frequently messages are retransmitted.

[ slide 268 ]

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

But that would require specifying:

How long it can take a message to be received.

How often messages can be lost.

And how frequently messages are retransmitted.

[ slide 269 ]

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

But that would require specifying:

How long it can take a message to be received.

How often messages can be lost.

And how frequently messages are retransmitted.

[ slide 270 ]

It’s simpler to require that a message iseventually received.

If it’s not eventually received, it can’t be receivedwithin 4.7 ms.

For systems without hard real-time response requirements,liveness checking is a useful way to find errors that preventthings from happening.

It’s simpler to require that a message is eventually received.

And if it’s not eventually received, it certainly can’t be received within 4.7milliseconds.

For systems without hard real-time response requirements,

liveness checking is a useful way to find errors that prevent things fromhappening.

[ slide 271 ]

It’s simpler to require that a message iseventually received.

If it’s not eventually received, it can’t be receivedwithin 4.7 ms.

For systems without hard real-time response requirements,liveness checking is a useful way to find errors that preventthings from happening.

It’s simpler to require that a message is eventually received.

And if it’s not eventually received, it certainly can’t be received within 4.7milliseconds.

For systems without hard real-time response requirements,

liveness checking is a useful way to find errors that prevent things fromhappening.

[ slide 272 ]

It’s simpler to require that a message iseventually received.

If it’s not eventually received, it can’t be receivedwithin 4.7 ms.

For systems without hard real-time response requirements,liveness checking is a useful way to find errors that preventthings from happening.

It’s simpler to require that a message is eventually received.

And if it’s not eventually received, it certainly can’t be received within 4.7milliseconds.

For systems without hard real-time response requirements,

liveness checking is a useful way to find errors that prevent things fromhappening.

[ slide 273 ]

It’s simpler to require that a message iseventually received.

If it’s not eventually received, it can’t be receivedwithin 4.7 ms.

For systems without hard real-time response requirements,liveness checking is a useful way to find errors that preventthings from happening.

It’s simpler to require that a message is eventually received.

And if it’s not eventually received, it certainly can’t be received within 4.7milliseconds.

For systems without hard real-time response requirements,

liveness checking is a useful way to find errors that prevent things fromhappening.

[ slide 274 ]

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Many systems use timeouts only to ensure that something must happen.By using timeouts only for that purpose, I mean thatcorrectness of such a system does not depend on how long it takes thetimeouts to occur.

That can influence only performance.

[ slide 275 ]

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Many systems use timeouts only to ensure that something must happen.By using timeouts only for that purpose, I mean thatcorrectness of such a system does not depend on how long it takes thetimeouts to occur.

That can influence only performance.

[ slide 276 ]

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Many systems use timeouts only to ensure that something must happen.By using timeouts only for that purpose, I mean thatcorrectness of such a system does not depend on how long it takes thetimeouts to occur.

That can influence only performance.

[ slide 277 ]

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

That can influence only performance.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Many systems use timeouts only to ensure that something must happen.By using timeouts only for that purpose, I mean thatcorrectness of such a system does not depend on how long it takes thetimeouts to occur.

That can influence only performance.

[ slide 278 ]

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Specifications of these systems can describe timeouts as actions with notime constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it can take anenabled operation (such as receiving a message) to occur.

[ slide 279 ]

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Specifications of these systems can describe timeouts as actions with notime constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it can take anenabled operation (such as receiving a message) to occur.

[ slide 280 ]

In the first eight lectures, you learned about writing the safety part of a TLA+ spec.Now you know how to specify liveness. You simply add weak and strong fairnessconditions. Simple, yes. Easy, no. Liveness is inherently subtle. TLA+ is the simplestway I know to express it, and it’s still hard.

But don’t worry if you have trouble with liveness. The safety part is by far the largestpart and almost always the most important part of a spec. A major reason to addliveness is to catch errors in the safety part. If your fairness conditions don’t imply theeventually or leads-to properties you expect to hold, it could be because the safety partdoesn’t allow behaviors that it should.[ slide 281 ]

TLA+ Video Course

End of Lecture 9, Part 2

THE ALTERNATING BIT PROTOCOLTHE PROTOCOL

[ slide 282 ]