We have seen how to use TLA to write abstract programs and show that they satisfy simple safety and liveness properties. In this chapter, we pause in our development to consider two problems. The first is determining if an abstract program written in TLA expresses what we want it to. We consider an approach to this problem that is different from what we have been doing—determining what the program might do, rather than what it must or must not do. The second problem is describing and reasoning about the real-time behavior of systems. I hope that seeing how this problem is addressed with TLA helps you appreciate the power of thinking of an abstract program as a predicate on behaviors rather than a generator of behaviors.

We have seen how to write the safety property of an abstract program in TLA. We now see how to write its liveness property. This chapter precisely defines safety and liveness properties, and shows why and how the liveness property of an abstract program is written as a particular kind of liveness property called a fairness property. In principle, any property that can be described mathematically can be expressed in TLA by such an abstract program. The chapter also shows how to use TLA to prove that a program satisfies a liveness property.

We will write an abstract program as a mathematical formula. A program can be quite complex, leading to a long formula. A long formula with a lot of esoteric mathematics would be impossible to understand. So, almost all the math used in our formulas is ordinary math, consisting of arithmetic, simple logic, sets, and functions. You should know most of it already if you took an introductory university math course for computer science or engineering students. Ordinary math does not include the temporal logic introduced in Sections 3.4 and 3.5.

This chapter covers two topics that, to my knowledge, have not yet seen any industrial application. However, they might in the future become useful. The first topic is reduction, which is about verifying that a program satisfies a property by verifying that a coarser-grained version of the program satisfies it. Even if you never use it, understanding the principles behind reduction can help you choose the appropriate grain of atomicity for abstract programs. For that purpose, skimming through Sections 8.1.1–8.1.3 should suffice.

In this chapter, we take a leisurely path that begins with a conventional mathematical method of describing computer systems and ends with the definition of almost all of TLA. Along the way, you will learn how to describe the safety part of an abstract program, how to prove it satisfies invariance properties, and the temporal logic that will be used to describe its safety and liveness properties as a single formula.

Dear Reader. I am inviting you to spend many pages with me. Before deciding whether to accept my invitation, you may want to know who I am.

We have discussed one abstract program implementing another. We now consider more carefully what that means. We write abstract programs with TLA formulas, and it is rather weird to talk about one formula implementing another. Computer scientists who view programs mathematically generally use the term refinement rather than implementation. Henceforth, we will use the two terms interchangeably.

An auxiliary variable is a variable that is added to an abstract program without altering the values assumed by the program’s regular variables. It’s sometimes necessary to add auxiliary variables to a program in order to prove that it refines another program. Sections 7.2, 7.3, and 7.4 define the three kinds of auxiliary variables that may be needed, illustrating them with silly little examples. Section 7.6 describes a realistic example that makes use of all three kinds of auxiliary variables. We begin with a section that explains variable hiding, which is the basis for auxiliary variables and is also used in Chapter 8.