 Shopping Bag ( 0 items )

All (8) from $21.95

New (4) from $39.36

Used (4) from $21.95
More About This Textbook
Overview
"TLA+ represents the only effective methodology I've seen for visualizing and quantifying algorithmic complexity in a way that is meaningful to engineers."
Brannon Batson, Processor Architect, Intel Corporation
This longawaited book shows how to write unambiguous specifications of complex computer systems.
The first part provides a concise and lucid introduction to specification, explaining how to describe, with mathematical precision, the behavioral properties of a systemwhat that system is allowed to do. The emphasis here is on safety properties.
The second part of the book covers more advanced topics, including liveness and fairness, realtime properties, and composition.
The book's final two parts provide a complete reference manual for the TLA+ language and tools, as well as a handy minimanual. TLA+ is the language developed by the author for writing simple and elegant specifications of algorithms and protocols and for verifying the correctness of a design. The language already has proved to be a valuable aid in understanding and building concurrent and distributed systems. Tools for TLA+ syntax analysis and model checking are freely available from the Web, where you can also find supplemental materials for this book, including exercises.
032114306XB06262002
Editorial Reviews
From The Critics
This book provides a guide to the writing of unambiguous specifications of complex computer systems. It explains how to describe, with mathematical precision, the behavior properties of a system. Safety properties are stressed, but topics like liveliness, fairness, and real time are also covered. The book also supplies a reference manual for the TLA+ language and tools. Lamport is a computer scientist, best known for creating the LaTeX typesetting program. Annotation c. Book News, Inc., Portland, ORProduct Details
Related Subjects
Meet the Author
Leslie Lamport, a computer scientist, is well known for his contributions to concurrent computing and distributed systems. His "Time, Clocks, and the Ordering of Events in a Distributed System" paper has been honored for its enduring influence on the field. Lamport is also known for creating the LaTeX typesetting system and the bestselling book, LaTeX, Second Edition, which documents it (AddisonWesley, 1994). Now at Microsoft Research in Mountain View, California, he began his work on TLA+ at the Digital (later Compaq) Systems Research Center in Palo Alto. Lamport, who earned his Ph.D. in mathematics from Brandeis University, is a member of the National Academy of Engineering.
032114306XAB06262002
Read an Excerpt
This book will teach you how to write specifications of computer systems, using the language TLA+. It's rather long, but most people will read only Part I, which comprises the first 83 pages. That part contains all that most engineers need to know about writing specifications; it assumes only the basic background in computing and knowledge of mathematics expected of an undergraduate studying engineering or computer science. Part II contains more advanced material for more sophisticated readers. The remainder of the book is a reference manual—Part III for the TLA+ tools and Part IV for the language itself.
The TLA World Wide Web page contains material to accompany the book, including the TLA+ tools, exercises, references to the literature, and a list of corrections.
What Is a Specification?
Writing is nature's way of letting you know how sloppy your thinking is.
Guindon
A specification is a written description of what a system is supposed to do. Specifying a system helps us understand it. It's a good idea to understand a system before building it, so it's a good idea to write a specification of a system before implementing it.
This book is about specifying the behavioral properties of a system—also called its functional or logical properties. These are the properties that specify what the system is supposed to do. There are other important kinds of properties that we don't consider, including performance properties. Worstcase performance can often be expressed as a behavioral property—for example, Chapter 9 explains how to specify that a system must reactwithin a certain length of time. However, specifying average performance is beyond the scope of the methods described here.
Our basic tool for writing specifications is mathematics. Mathematics is nature's way of letting you know how sloppy your writing is. It's hard to be precise in an imprecise language like English or Chinese. In engineering, imprecision can lead to errors. To avoid errors, science and engineering have adopted mathematics as their language.
The mathematics we use is more formal than the math you've grown up with. Formal mathematics is nature's way of letting you know how sloppy your mathematics is. The mathematics written by most mathematicians and scientists is not really precise. It's precise in the small, but imprecise in the large. Each equation is a precise assertion, but you have to read the accompanying words to understand how the equations relate to one another and exactly what the theorems mean. Logicians have developed ways of eliminating those words and making the mathematics completely formal, and hence completely precise.
Most mathematicians and scientists think that formal mathematics, without words, is long and tiresome. They're wrong. Ordinary mathematics can be expressed compactly in a precise, completely formal language. It takes only about two dozen lines to define the solution to an arbitrary differential equation in the Differential Equations module of Chapter 11. But few specifications need such sophisticated mathematics. Most require only simple application of a few standard mathematical concepts.
Why TLA+?
We specify a system by describing its allowed behaviors—what it may do in the course of an execution. In 1977, Amir Pnueli introduced the use of temporal logic for describing system behaviors. In principle, a system could be described by a single temporal logic formula. In practice, it couldn't. Pnueli's temporal logic was ideal for describing some properties of systems, but awkward for others. So, it was usually combined with a more traditional way of describing systems.
In the late 1980s, I invented TLA, the Temporal Logic of Actions—a simple variant of Pnueli's original logic. TLA makes it practical to describe a system by a single formula. Most of a TLA specification consists of ordinary, nontemporal mathematics. Temporal logic plays a significant role only in describing those properties that it's good at describing. TLA also provides a nice way to formalize the style of reasoning about systems that has proved to be most effective in practice—a style known as assertional reasoning. However, this book is about specification; it says almost nothing about proofs.
Temporal logic assumes an underlying logic for expressing ordinary mathematics. There are many ways to formalize ordinary math. Most computer scientists prefer one that resembles their favorite programming language. I chose instead the one that most mathematicians prefer—the one logicians call firstorder logic and set theory.
TLA provides a mathematical foundation for describing systems. To write specifications, we need a complete language built atop that foundation. I initially thought that this language should be some sort of abstract programming language whose semantics would be based on TLA. I didn't know what kind of programming language constructs would be best, so I decided to start writing specifications directly in TLA. I intended to introduce programming constructs as I needed them. To my surprise, I discovered that I didn't need them. What I needed was a robust language for writing mathematics.
Although mathematicians have developed the science of writing formulas, they haven't turned that science into an engineering discipline. They have developed notations for mathematics in the small, but not for mathematics in the large. The specification of a real system can be dozens or even hundreds of pages long. Mathematicians know how to write 20line formulas, not 20page formulas. So, I had to introduce notations for writing long formulas. What I took from programming languages were ideas for modularizing large specifications.
The language I came up with is called TLA+. I refined TLA+ in the course of writing specifications of disparate systems. But it has changed little in the last few years. I have found TLA+ to be quite good for specifying a wide class of systems—from program interfaces (APIs) to distributed systems. It can be used to write a precise, formal description of almost any sort of discrete system. It's especially well suited to describing asynchronous systems—that is, systems with components that do not operate in strict lockstep.
About This Book
Part I, consisting of Chapters 1 through 7, is the core of the book and is meant to be read from beginning to end. It explains how to specify the class of properties known as safety properties. These properties, which can be specified with almost no temporal logic, are all that most engineers need to know about. After reading Part I, you can read as much of Part II as you like. Each of its chapters is independent of the others. Temporal logic comes to the fore in Chapter 8, where it is used to specify the additional class of properties known as liveness properties. Chapter 9 describes how to specify realtime properties, and Chapter 10 describes how to write specifications as compositions. Chapter 11 contains more advanced examples.
The three chapters in Part III serve as the reference manual for three TLA+ tools: the Syntactic Analyzer, the TLATEX typesetting program, and the TLC model checker. If you want to use TLA+, then you probably want to use these tools. They are available from the TLA Web page. TLC is the most sophisticated of them. The examples on the Web can get you started using it, but you'll have to read Chapter 14 to learn to use TLC effectively.
Part IV is a reference manual for the TLA+ language. Part I provides a good enough working knowledge of the language for most purposes. You need look at Part IV only if you have questions about the fine points of the syntax and semantics. Chapter 15 gives the syntax of TLA+. Chapter 16 describes the precise meanings and the general forms of all the builtin operators of TLA+; Chapter 17 describes the precise meaning of all the higherlevel TLA+ constructs such as definitions. Together, these two chapters specify the semantics of the language. Chapter 18 describes the standard modules—except for module RealTime, described in Chapter 9, and module TLC, described in Chapter 14. You might want to look at this chapter if you're curious about how standard elementary mathematics can be formalized in TLA+.
Part IV does have something you may want to refer to often: a minimanual that compactly presents lots of useful information. Pages 268273 list all TLA+ operators, all userdefinable symbols, the precedence of all operators, all operators defined in the standard modules, and the ASCII representation of symbols.
Table of Contents
List of Figures and Tables.
Acknowledgments.
Introduction.
I. Getting Started.
1. A Little Simple Math.
Propositional Logic.
Sets.
Predicate Logic.
Formulas and Language.
2. Specifying a Simple Clock.
Behaviors.
An Hour Clock.
A Closer Look at the Specification.
The Specification in TLA+.
An Alternative Specification.
3. An Asynchronous Interface.
The First Specification.
Another Specification.
Types: A Reminder.
Definitions.
Comments.
4. A FIFO.
The Inner Specification.
Instantiation Examined.
Instantiation Is Substitution.
Parametrized Instantiation.
Implicit Substitutions.
Instantiation Without Renaming.
Hiding the Queue.
A Bounded FIFO.
What We're Specifying.
5. A Caching Memory.
The Memory Interface.
Functions.
A Linearizable Memory.
Tuples as Functions.
Recursive Function Definitions.
A WriteThrough Cache.
Invariance.
Proving Implementation.
6. Some More Math.
Sets.
Silly Expressions.
Recursion Revisited.
Functions versus Operators.
Using Functions.
Choose.
7. Writing a Specification: Some Advice.
Why Specify.
What to Specify.
The Grain of Atomicity.
The Data Structures.
Writing the Specification.
Some Further Hints.
When and How to Specify.
II: More Advanced Topics.
8. Liveness and Fairness.
Temporal Formulas.
Temporal Tautologies.
Temporal Proof Rules.
Weak Fairness.
The Memory Specification.
The Liveness Requirement.
Another Way to Write It.
A Generalization.
Strong Fairness.
The WriteThrough Cache.
Quantification.
Temporal Logic Examined.
A Review.
Machine Closure.
Machine Closure and Possibility.
Refinement Mappings and Fairness.
The Unimportance of Liveness.
Temporal Logic Considered Confusing.
9. Real Time.
The Hour Clock Revisited.
RealTime Specifications in General.
A RealTime Caching Memory.
Zeno Specifications.
Hybrid System Specifications.
Remarks on Real Time.
10. Composing Specifications.
Composing Two Specifications.
Composing Many Specifications.
The FIFO.
Composition with Shared State.
Explicit State Changes.
Composition with Joint Actions.
A Brief Review.
A Taxonomy of Composition.
Interleaving Reconsidered.
Joint Actions Reconsidered.
Liveness and Hiding.
Liveness and Machine Closure.
Hiding.
OpenSystem Specifications.
Interface Refinement.
A Binary Hour Clock.
Refining a Channel.
Interface Refinement in General.
OpenSystem Specifications.
Should You Compose?.
11. Advanced Examples.
Specifying Data Structures.
Local Definitions.
Graphs.
Solving Differential Equations.
BNF Grammars.
Other Memory Specifications.
The Interface.
The Correctness Condition.
A Serial Memory.
A Sequentially Consistent Memory.
The Memory Specifications Considered.
III: The Tools.
12. The Syntactic Analyzer.
13. The TLATEX Typesetter.
Introduction.
Comment Shading.
How It Typesets the Specification.
How It Typesets Comments.
Adjusting the Output Format.
Output Files.
TroubleShooting.
Using LATEX Commands.
14. The TLC Model Checker.
Introduction to TLC.
What TLC Can Cope With.
TLC Values.
How TLC Evaluates Expressions.
Assignment and Replacement.
Evaluating Temporal Formulas.
Overriding Modules.
How TLC Computes States.
How TLC Checks Properties.
ModelChecking Mode.
Simulation Mode.
Views and Fingerprints.
Taking Advantage of Symmetry.
Limitations of Liveness Checking.
The TLC Module.
How to Use TLC.
Running TLC.
Debugging a Specification.
Hints on Using TLC Effectively.
What TLC Doesn't Do.
The Fine Print.
The Grammar of the Configuration File.
Comparable TLC Values.
IV: The TLA+ Language.
MiniManual 268273.
15. The Syntax of TLA+.
The Simple Grammar.
The Complete Grammar.
Precedence and Associativity.
Alignment.
Comments.
Temporal Formulas.
Two Anomalies.
The Lexemes of TLA+.
16. The Operators of TLA+.
Constant Operators.
Boolean Operators.
The Choose Operator.
Interpretations of Boolean Operators.
Conditional Constructs.
The Let/In Construct.
The Operators of Set Theory.
Functions.
Records.
Tuples.
Strings.
Numbers.
. Nonconstant Operators.
Basic Constant Expressions.
The Meaning of a State Function.
Action Operators.
Temporal Operators.
17. The Meaning of a Module.
Operators and Expressions.
The Order and Arity of an Operator.
¿¿ Expressions.
Simplifying Operator Application.
Expressions.
Levels.
Contexts.
The Meaning of a ¿¿ Expression.
The Meaning of a Module.
Extends.
Declarations.
Operator Definitions.
Function Definitions.
Instantiation.
Theorems and Assumptions.
Submodules.
Correctness of a Module.
Finding Modules.
The Semantics of Instantiation.
18. The Standard Modules.
Module Sequences.
Module FiniteSets.
Module Bags.
The Numbers Modules.
Index. 032114306XT07022002
Preface
This book will teach you how to write specifications of computer systems, using the language TLA+. It's rather long, but most people will read only Part I, which comprises the first 83 pages. That part contains all that most engineers need to know about writing specifications; it assumes only the basic background in computing and knowledge of mathematics expected of an undergraduate studying engineering or computer science. Part II contains more advanced material for more sophisticated readers. The remainder of the book is a reference manualPart III for the TLA+ tools and Part IV for the language itself.
The TLA World Wide Web page contains material to accompany the book, including the TLA+ tools, exercises, references to the literature, and a list of corrections. There is a link to the TLA Web page on http://lamport.org. You can also find the page by searching the Web for the 21letter string. Do not put this string in any document that might appear on the Web.
What Is a Specification?
Writing is nature's way of letting you know how sloppy your thinking is.
Guindon
A specification is a written description of what a system is supposed to do. Specifying a system helps us understand it. It's a good idea to understand a system before building it, so it's a good idea to write a specification of a system before implementing it.
This book is about specifying the behavioral properties of a systemalso called its functional or logical properties. These are the properties that specify what the system is supposed to do. There are other important kinds of properties that we don't consider, including performance properties. Worst case performance can often be expressed as a behavioral propertyfor example, Chapter 9 explains how to specify that a system must react within a certain length of time. However, specifying average performance is beyond the scope of the methods described here.
Our basic tool for writing specifications is mathematics. Mathematics is nature's way of letting you know how sloppy your writing is. It's hard to be precise in an imprecise language like English or Chinese. In engineering, imprecision can lead to errors. To avoid errors, science and engineering have adopted mathematics as their language.
The mathematics we use is more formal than the math you've grown up with. Formal mathematics is nature's way of letting you know how sloppy your mathematics is. The mathematics written by most mathematicians and scientists is not really precise. It's precise in the small, but imprecise in the large. Each equation is a precise assertion, but you have to read the accompanying words to understand how the equations relate to one another and exactly what the theorems mean. Logicians have developed ways of eliminating those words and making the mathematics completely formal and, hence, completely precise.
Most mathematicians and scientists think that formal mathematics, without words, is long and tiresome. They're wrong. Ordinary mathematics can be expressed compactly in a precise, completely formal language. It takes only about two dozen lines to define the solution to an arbitrary differential equation in the DifferentialEquations module of Chapter 11. But few specifications need such sophisticated mathematics. Most require only simple application of a few standard mathematical concepts.
Why TLA+?
We specify a system by describing its allowed behaviorswhat it may do in the course of an execution. In 1977, Amir Pnueli introduced the use of temporal logic for describing system behaviors. In principle, a system could be described by a single temporal logic formula. In practice, it couldn't. Pnueli's temporal logic was ideal for describing some properties of systems, but awkward for others. So, it was usually combined with a more traditional way of describing systems.
In the late 1980's, I invented TLA, the Temporal Logic of Actionsa simple variant of Pnueli's original logic. TLA makes it practical to describe a system by a single formula. Most of a TLA specification consists of ordinary, nontemporal mathematics. Temporal logic plays a significant role only in describing those properties that it's good at describing. TLA also provides a nice way to formalize the style of reasoning about systems that has proved to be most effective in practicea style known as assertional reasoning. However, this book is about specification; it says almost nothing about proofs.
Temporal logic assumes an underlying logic for expressing ordinary mathematics. There are many ways to formalize ordinary math. Most computer scientists prefer one that resembles their favorite programming language. I chose instead the one that most mathematicians preferthe one logicians call first order logic and set theory.
TLA provides a mathematical foundation for describing systems. To write specifications, we need a complete language built atop that foundation. I initially thought that this language should be some sort of abstract programming language whose semantics would be based on TLA. I didn't know what kind of programming language constructs would be best, so I decided to start writing specifications directly in TLA. I intended to introduce programming constructs as I needed them. To my surprise, I discovered that I didn't need them. What I needed was a robust language for writing mathematics.
Although mathematicians have developed the science of writing formulas, they haven't turned that science into an engineering discipline. They have developed notations for mathematics in the small, but not for mathematics in the large. The specification of a real system can be dozens or even hundreds of pages long. Mathematicians know how to write 20line formulas, not 20page formulas. So, I had to introduce notations for writing long formulas. What I took from programming languages were ideas for modularizing large specifications.
The language I came up with is called TLA+. I refined TLA+ in the course of writing specifications of disparate systems. But it has changed little in the last few years. I have found TLA+ to be quite good for specifying a wide class of systemsfrom program interfaces (APIs) to distributed systems. It can be used to write a precise, formal description of almost any sort of discrete system. It's especially well suited to describing asynchronous systemsthat is, systems with components that do not operate in strict lockstep.
About this Book
Part I, consisting of Chapters 1 through 7, is the core of the book and is meant to be read from beginning to end. It explains how to specify the class of properties known as safety properties. These properties, which can be specified with almost no temporal logic, are all that most engineers need to know about.
After reading Part I, you can read as much of Part II as you like. Each of its chapters is independent of the others. Temporal logic comes to the fore in Chapter 8, where it is used to specify the additional class of properties known as liveness properties. Chapter 9 describes how to specify realtime properties, and Chapter 10 describes how to write specifications as compositions. Chapter 11 contains more advanced examples.
Part III serves as the reference manual for three TLA+ tools: the Syntactic Analyzer, the TLATEX typesetting program, and the TLC model checker. If you want to use TLA+, then you probably want to use these tools. They are available from the TLA Web page. TLC is the most sophisticated of them. The examples on the Web can get you started using it, but you'll have to read Chapter 14 to learn to use TLC effectively.
Part IV is a reference manual for the TLA+ language. Part I provides a good enough working knowledge of the language for most purposes. You need look at Part IV only if you have questions about the fine points of the syntax and semantics. Chapter 15 gives the syntax of TLA+. Chapter 16 describes the precise meanings and the general forms of all the builtin operators of TLA+; Chapter 17 describes the precise meaning of all the higherlevel TLA+ constructs such as definitions. Together, these two chapters specify the semantics of the language. Chapter 18 describes the standard modulesexcept for module RealTime, described in Chapter 9, and module TLC, described in Chapter 14. You might want to look at this chapter if you're curious about how standard elementary mathematics can be formalized in TLA+.
Part IV does have something you may want to refer to often: a minimanual that compactly presents lots of useful information. Pages 268273 list all TLA+ operators, all userdefinable symbols, the precedence of all operators, all operators defined in the standard modules, and the ASCII representation of symbols.
032114306XP07022002