为了防止身体整体在“脚尖-脚跟”方向晃动，可以略微有踮脚的意识，让重心靠近脚掌。
为了防止身体朝靶或远离靶晃动，要注意背部用力开弓，前后对称用力。
勾弦注意食指中指不要夹到箭。在拉开弦后，呈角度的弓弦会压拢手指，要注意此时也不要夹到箭。
推弓时要注意不要向上下用力，弓不要位于手臂延长线的左右，因为偏离中心的用力在撒放会让弓身转动，带来干扰。
举弓要举稳后再把弓拉开。举弓后两手动作不要调整。
举弓时要沉肩。拉弓臂手肘要高过肩膀。
开弓后不要进行二次瞄准，手肘高低也要一次到位。
用力时头不要靠近、远离弓，重心也不要向四周晃动。
开弓臂手腕不要弯曲，保证手背跟前臂呈一条直线。
可以通过鼻、口、下巴、胸与弓弦接触，食指靠在颌骨旁，来保证每次靠弦一致。胸部接触可以防止头前后移动。
要保证靠弦最短距离、一步到位。
嘴唇闭住，保证触弦位置一致。
手肘略微顺时针旋转，保证持弓臂的肩、手肘、手施力点在俯视上为一条直线。手与前肩持平或略高。
两臂肩关节尽量靠近箭杆。两肩保持沉肩。
拉弓臂手肘高于肩膀，后背用力，手指放松，调整手腕使手背手臂打平。保证勾弦点、搭箭点、靶中心在一条直线上。勾弦点位于身体重心正上方。
身体略微前倾但重心不要超过脚尖，能够保证不晃动，同时可以保证肩部容易沉肩、后背容易收紧。
使眼睛聚焦在瞄准器上，瞄实靶虚。
瞄准时间保持在 2 至 4 秒。
手不要用力顶住脸。
在有信号片的弓上，保持动作继续缓慢开弓直到信号片响。
后背继续用力带动拉弓臂手肘向后背移动，同时手指自然伸直。手指可以擦过脖子。撒放的同时，身体重心可以稍微向脚尖移动，但不要过大。推弓手不要握弓，避免撒放的反作用力传到弓上。撒放结束后，拉弓臂手肘应当越过中轴线，位于后背侧，手肘不要下垂。
手指放松，手指根部尽量与手背平直。撒放时不要主动用力伸直。勾弦手保持与手臂在一条直线上，不自然的角度会导致撒放时部分手指滑弦或过早离弦。
撒放完成后，停留 2 至 3 秒，感受并强化正确动作。
]]>TLC 是检查 TLA+ 错误的程序，它能够处理Spec == Init /\ [][Next]_<<vars>> /\ Temporal形式的大部分规范，这通过在配置文件中使用关键字SPECIFICATION Spec指定。如果规范不包含时序逻辑，也可以使用INIT Init和NEXT Next指定。TLC 中要检查的规范叫做模型。
TLC 不能处理\EE运算符，用户应当单独检查\EE涉及的子规范。这可以通过 5.8 节介绍的，为要使用\EE隐藏的变量在实例化时显式指定映射来绕过。
TLC 可以检查如下种类的情况：
无意义的表达式（6.2 节）
死锁，即Next步的前提不能被满足。但有的系统允许死锁表示系统按预期终止
使用PROPERTY关键字检查某公式是否为真。TLC 实际上并不是检查Spec => Prop，而是对于SPECIFICATION和PROPERTY分拆安全性和活跃性部分，分别检查
SPECIFICATION的安全性蕴含PROPERTY安全性
SPECIFICATION蕴含PROPERTY的活跃性
由于PROPERTY的安全性和活跃性分别检查，因此 TLC 不能处理两者相互影响的情况，也即不能处理非状态机闭包
如果想要表达公式一直为真，可以使用[]或者INVARIANT关键字描述。如果使用INVARIANT关键字，要检查的必须是一个单状态公式
TLC 在开始检查前需要指定规范中常数参数的取值。
TLC 有两种工作模式，检查所有可到达的状态，即模型检查模式；或者随机生成状态作为系统行为，即模拟模式。本节我们先讨论前者。
对于状态过多、或者无穷状态的规范，我们可以指定约束限制一些不必要状态，这可以使用CONSTRAINT关键字指定约束公式。
TLC 对于不同类型公式的检查速度不同，建议按照类型不变量、检查安全性、检查活跃性的顺序进行检查。完成检查后，我们还可以编写一个“事后规范”，检查规范是否能蕴含这个“事后规范”。
TLA+ 的描述性太强，不存在能检查 TLA+ 所有规范的工具。TLC 能处理 TLA+ 的大多数情况。
TLC 能表达的值比 TLA+ 更有限，TLC 值的四种基本类型是布尔型、整数、字符串、作为常量符号的模型值。TLC 值是由
基本类型
可比较的 TLC 值构成的有限集
定义域和值域全部是 TLC 值的函数
组成。两个值可比较的定义是 TLA+ 语义下两个值可以判断是否相等。字符串和数字在 TLA+ 中是不能判断相等的。包含不同个数元素的集合，即使元素分别是是字符串和数字，是可以判断不相等的。更精确的定义见 14.7.2
检查规范的过程就是对表达式求值，查看结果是否为真的过程。
TLC 有短路特性，以此避免越界。
TLC 只能处理绑定变量\E x \in S: p的表达式，而且S必须是有限集。与 TLA+ 不同，TLC 不能处理未绑定变量的表达式\E x: p。
TLC 在CHOOSE无法取到合法的值时会报错。
TLC 仅在需要的时候求值，例如[n \in Nat |-> n * (n + 1)][3]中Nat不是有限集，但可以求值。
TLC 对于合法的递归表达式有时不能求值，例如 6.3 节使用record.f和record.g解决依赖多个函数的问题。TLC 会完全对record求值，再取它的成员，因此有些情况下会造成自我依赖，进入死循环。
TLC 的赋值指的是配置文件CONSTANT部分c = v形式的语句。v必须是一个 TLC 值，或者是 TLC 值的有限集。v可以包含模型中的某个变量，即模型值，作为一个常量符号。c可以是规范中定义的符号或者常数参数，TLC 会对其进行赋值或者覆盖。覆盖常常用于使用模型值表示 TLC 不能表达的 TLA+ 表达式，为了提高可读性，一般写作symbol = symbol。
CONSTANT部分可以应用替换，表示成c <- d的形式。替换与复制的区别是替换的d需要是有定义的符号，而v需要是 TLC 值。替换可以用于，在一个简单、快速写成的规范中用更高效的实现替换部分标识符。
TLC 可以对满足如下条件的 TLA+ 时序逻辑公式求值：表达式良定义并且其“组成部分”都可以求值。良定义指的是表达式由如下四种公式合取而成：
单状态公式
不变量公式[]P，其中P是单状态公式
[][A]_v，其中A是动作v是单状态公式
由如下两种合取而成的公式
单状态时序逻辑公式，既不包含'变量
满足公平性、[]<><<A>>_v、<>[][A]_v的形式，其中A是动作v是单状态公式。公平性的“组成部分”是<<A>>_v和ENABLED <<A>>_v
TLC 支持使用 Java 实现覆盖模块，标准模块Naturals，Integers，Sequences，FiniteSets，Bags已经被覆盖。
状态就是所有变量都具有对应的值，TLC 将不带'的变量计算对应的值，然后计算Next公式。Next公式的计算与 14.2.2 节提到的计算有两点不同：
析取子式（包括\/，\E，=>）隔离计算。合取子式仍然会依次计算并提前终止。
对于第一次出现的'的变量x' = e进行赋值并对公式返回TRUE。除这种情况以外，TLC 会对'的变量的访问报错。
对于ENABLED A这种公式，TLC 把A作为Next公式进行计算，如果有至少一个可达状态，ENABLED A的值就为真。
14.1 节介绍 TLC 有两种工作状态，检查所有行为或者随机模拟一些行为。首先我们介绍前者。
将 TLC 配置文件中的各段进行整理，可以得到如下几类公式。定义某类公式为空表示为真：
Init，由INIT指定，或者是SPECIFICATION中所有单状态公式的合取
Next，由NEXT指定，或者是SPECIFICATION中所有形如[][N]_v的N合取
Temporal，SPECIFICATION中既不是单状态公式也不是[][N]_v的公式合取，通常表达活跃性
Invariant，由INVARIANT指定，或者是PROPERTY中形如[][I]的I合取
ImpliedInit，PROPERTY中单状态公式的合取
ImpliedAction，PROPERTY中形如[][A]_v的[A]_v合取
ImpliedTemporal，PROPERTY中除Invariant以外的时序逻辑公式
Constraint，由CONSTRAINT指定
ActionConstraint，由ACTION-CONSTRAINT指定。该类公式与Constraint类似，但是Constraint排除了一些状态，ActionConstraint排除了一些状态转移。Constraint P等价于ActionConstraint P'
该模式下 TLC 维护两个数据结构：有向图G的点集、边集分别存储可达的状态和转移，队列U存储G中尚未检查邻接点合法性的点。
TLC 维护的不变量包括：
G中的状态满足Constraint
G中的状态有自环边
G中的状态是由满足Init的状态可达的
G中的边满足Next /\ ActionConstraint
U中的点不重复，且都在G中
对于G中不在U中的点s，如果t满足Constraint且边(s, t)满足Next /\ ActionConstraint，那么t和(s, t)也在G中
TLC 按照如下流程进行检查：
检查 TLC 常数参数的指定是符合ASSUME的
按照Init计算初始状态。对于每个初始状态s：
检查Invariant和ImpliedInit
如果s满足Constraint，将s添加到G和U中，将(s, s)添加到G中
当U不为空时：
队首出队，记为s
计算s所有可达的状态，记为集合T
如果T是空集而且 TLC 配置为不允许死锁，报告错误
对于T中的每个状态t：
检查t满足Invariant，(s, t)满足ImpliedAction
如果t满足Constraint且(s, t)满足ActionConstraint：
t不在G中，将其加到G中，并在U的队尾入队。(s, t)、(t, t)加到G中如果ImpliedTemporal不为空，在G每次加边时 TLC 都会为新增加的边求出Temporal和ImpliedTemporal的值。TLC 周期性检查G中由初始状态出发形成的无限长的路径是否满足Temporal => ImpliedTemporal。
模拟模式不尝试检查所有的状态，因此可以看作U的最大长度限制为 1。在行为的状态数达到设定值的时候，TLC 进行时序逻辑相关性质的检查，并将G和U恢复到初始状态重新进行模拟。
在模型检查模式中，G中的节点实际上是视图而不是状态，这么做的原因是视图可以控制仅用部分变量区分G的点。视图在配置文件的VIEW进行指定。视图常见的应用是，用户为了调试规范增加了一些辅助变量，但是这样会增大搜索空间，所以用视图指定为原始的非调试变量。
由于视图限制了一些状态加入G，TLC 可能会因此将时序逻辑性质判断错误。
在实现中，TLC 是通过视图的哈希，即指征进行区分。这样又引入了哈希碰撞引发的错误概率。TLC 会在模型检查的结果中汇报这种概率。
在模拟模式中，没有这两个概念以及它们潜在的错误。
对称性指轮换对称性，在配置文件中通过SYMMETRY Perms指定。Perms常常通过 TLC 模块的Permutations(S)运算符表示S的元素是满足轮换对称性的。在 TLC 增长G和U时检查轮换对称性引起的重复，从而避免添加不必要的状态。如果有多个集合S1，S2……，可以表达成Permutations(S1) \union Permutations(S2) ...。
TLC 同样会因为对称性跳过状态从而将时序逻辑性质判断错误。
在误用对称性时，TLC 会报告Failed to recover the state from its fingerprint.
对称性也是仅在模型检查模式有效。
在某些情况下，TLC 需要限制搜索空间的数目即G的大小，从而可能导致规范的活跃性不满足。例如对于
EvenSpec == (x = 0) /\ [][x' = x + 2]_x /\ WF_x(x' = x + 2)
检查<>(x = 1)。TLC 不能处理无穷的状态，为了检查能终止，需要用CONSTRAINT限制G的大小（此处为x的取值）。而x的限制取值会导致G产生的无穷行为末尾出现x保持不变的无限个状态，因此弱公平性为假。按照蕴含的定义，WF_x(x' = x + 2) => <>(x = 1)为真，也就是 TLC 没有检查出错误。
为了避免这个情况，可以用一个必定为假的活跃性性质，检查 TLC 有没有正常工作。
TLC 模块提供了一些辅助功能。
Print(out, val)运算符的值是val，但是 TLC 在对其进行求值时会打印out。
Assert(val, out)起到了断言的作用，如果val为假，TLC 会打印out并终止。
JavaTime会打印当前时间。
1 :> "ab" @@ 2 :> "cd"表示定义域为{1, 2}取值分别为{"ab", "cd"}的函数。
前文中提到的Permutations(S)定义如下：
Permutations(S) == {f \in [S -> S]: \A w \in S : \E v \in S : f[v] = w}
使用Permutations(S)和:>、@@运算符，我们可以表达更复杂的对称性。例如对于两个处理器p1、p2分别有相关的地址a11、a12和a21、a22，我们可以定义对称性为
Permutations({a11, a12}) \union {p1 :> p2 @@ p2 :> p1
@@ a11 :> a21 @@ a21 :> a11
@@ a12 :> a22 @@ a22 :> a12}
这个并集操作两边分别是交换第一个处理器相关的地址，以及交换两个处理器。可以验证所有的对称性可以通过这两个交换构造出来。
SortSeq(s, Op(_, _))运算符对序列按照全序运算符Op进行排序。
TLC 在运行时有诸多配置，包括：
-deadlock不检查死锁
-simulate模拟模式
-depth num模拟模式下行为的长度，默认为 100
-seed num模拟模式下随机数种子，取值在 -2^63 到 2^63 - 1 之间
-aril num模拟模式下影响初始化的随机数种子
-coverage num每隔num分钟打印赋值相关动作的执行覆盖情况
-recover run_id表示从run_id的存盘点继续
-cleanup清理临时文件，注意多个 TLC 实例运行时该选项会破坏运行中的实例
-difftrace num打印错误时使用在状态转移之间仅打印差异部分
-terse打印错误时打印精简的变量值
-workers num使用num个线程寻找可达状态，默认为 1
-config config_file表示使用config_file作为配置文件，默认与 TLA+ 文件同名
-nowarning不显示警告
TLC 在运行时会打印很多信息，这里仅介绍几个不直观的输出：
Implied-temporal checking--relative complexity = 8.
表示估计的时序逻辑公式相对于安全性公式的复杂度，这个值越高在检查活跃性时耗时越长。
Progress(9): 2846 states generated, 984 distinct states found. 856 states left on queue.
括号中的9表示直径，即G中从初始状态延伸的路径长度的最大值。在多线程情况下，这个值可能并不准确。856即为U的长度，一般而言整个过程中该长度先上升后下降。
-- Checkpointing run states/99-05-20-15-47-55 completed
states/99-05-20-15-47-55即为run_id存盘点。
先为模型的常数参数赋较小的值，再逐渐增大。模拟模式在运气好的时候也能暴露错误。
对“成功”结果表示怀疑，因为有些规范中的错误会导致搜索状态意外减少。这可以通过-coverage num选项的输出或者添加额外的检查条件来排查。
更高效利用 TLC，例如分拆不变量，使用Print打印变量的变化，将出错的状态设置为初始状态、Next公式从而快速出错。
出错后不要急着从头开始。先使用上一条中提到的“快速出错”确保错误已经被修复。另外由于存盘点只保存G和U，如果修正错误后的规范没有改变变量名，可以复用之前的存盘点。
尽量多检查各种性质。
TLC 的目的是检查错误，因此为了绕过 TLC 的限制可以使用替换等方式调整规范。比如对于Nat等无限大小的集合使用0..n代替。
使用ASSUME快速计算 TLA+ 中简单公式的值。
TLC 的限制还包括：Naturals和Integers模块的 Java 实现实际上只能处理 -2^63 到 2^63 - 1 之间的值。
TLC 的部分语义也与 TLA+ 不同。包括：TLC 的CHOOSE运算符只保证对句法上相同的集合选出相同的元素，因此不保证{1, 2}与{2, 1}选出相同的元素；字符串是基本数据类型而不是函数，因此取下标会报错。
配置文件的语法可以用 BNF 表示，详见原书。除此之外，INIT、NEXT定义只能有一次，SPECIFICATION定义只能出现一次且不能与INIT、NEXT同时出现。VIEW和SYMMETRY定义同样只能出现一次。除此以外的段都能定义多次。
满足如下规则的值是可比较的：
对于基本数据类型，如果类型相同就可比较
模型值总是可比较的，因为它仅与自己相等
集合的可比较定义为大小不同，或者大小相同且元素两两可比较
函数的可比较仅当定义域可比较，或者定义域相同且相同的x对应的值可比较
TLATeX 使用 LaTeX 作为排版引擎由 tla 文件输出 PDF 等更易读的文件。TLATeX 提供了显示行号、传递 LaTeX 命令等功能，详见文档。
TLATeX 可以控制注释区域的阴影深度，或者结合其他工具调整阴影。
规范的排版不会破坏跨行对齐。符号之间不使用空格与使用一个空格的排版相同。排版会将模块前后的文字一同处理，这种特性也可以被屏蔽。排版会检查部分词法错误。
TLATeX 会区分单行注释与多行注释。多行注释有如下三种写法：
(**************) \************* (* This
(* This is *) \* This is is a
(* a comment. *) \* a comment. comment. *)
(**************) \*************
其中前两种需要注意对齐。
多行注释的排版会自动检测段落、表格等多种情况进行折行，但不会进行跨行对齐。
注释的一些语法：
`这部分注释应用规范的样式（包括规范中的字符串样式）'
`^这部分注释应用注释的样式，交给 LaTeX 进行排版^'
`.这部分注释不进行排版，以 ASCII 形式输出.'
``本行首末是左右引号''
`~这部分注释不会显示~'
TLATeX 可以调整字号、文字高度宽度、偏移量。
TLATeX 可以配置输出文件的文件名、ASCII 版本的输出、LaTeX 样式。
TLATeX 会依次产生一些中间文件，并最终输出 PDF 等阅读文件。命令行输出和中间文件日志有助于定位问题。
通过
`^这部分注释应用注释的样式，交给 LaTeX 进行排版^'
这种方式使用 LaTeX 进行排版。由于 LaTeX 代码的可读性差，因此推荐使用如下方式同时维护一份 ASCII 可读的注释
\*************************************
\* `^ \begin{describe}{gnat:}
\* \item[gnat:] A tiny insect.
\* \item[gnu:] A short word.
\* \end{describe} ^'
\* `~ gnat: A tiny insect.
\*
\* gnu: A short word. ~'
\*************************************
在发现错误时，语法分析器会打印当前的解析栈辅助定义问题。
]]>LOCAL关键词可以控制所修饰的定义标识符以及实例化INSTANCE不导出到其他模块中，避免与其他模块的标识符冲突。但是LOCAL不能修饰变量、常量的声明，以及EXTENDS。
上一段说在LOCAL的语法上，INSTANCE和EXTENDS是不等同的。但是如果模块没有变量、常量的声明或者子模块，那么该模块的INSTANCE和EXTENDS效果一致（见 4.2.4 同名实例化），因此可以用INSTANCE导入并用LOCAL修饰。
我们以图为例解释如何定义一个数据结构，具体而言，定义一个没有外部声明的有向图Graphs模块，以方便图与图之间的运算。Graphs模块通过记录访问两个域，对应点集N、边集E。该模块对外提供如下运算符：
IsDirectedGraph(G)：当且仅当G的E是N \X N的子集。
DirectedSubgraph(G)：返回有向图G的所有子图。
IsUndirectedGraph(G)、UndirectedSubgraph(G)：将上述的运算符扩展到无向图，在Graphs模块中，无向边通过两条形成环的边表示。
Path(G)：图的路径。
AreConnectedIn(m, n, G)：两个点m和n是否是连通的。
在此省略定义的其他的运算符。Graphs模块如下：
------------------------------- MODULE Graphs -------------------------------
LOCAL INSTANCE Naturals
LOCAL INSTANCE Sequences
IsDirectedGraph(G) ==
/\ G = [node |-> G.node, edge |-> G.edge]
/\ G.edge \subseteq (G.node \X G.node)
DirectedSubgraph(G) ==
{H \in [node : SUBSET G.node, edge : SUBSET (G.node \X G.node)] :
IsDirectedGraph(H) /\ H.edge \subseteq G.edge}
-----------------------------------------------------------------------------
IsUndirectedGraph(G) ==
/\ IsDirectedGraph(G)
/\ \A e \in G.edge : <<e[2], e[1]>> \in G.edge
UndirectedSubgraph(G) == {H \in DirectedSubgraph(G) : IsUndirectedGraph(H)}
-----------------------------------------------------------------------------
Path(G) == {p \in Seq(G.node) :
/\ p /= << >>
/\ \A i \in 1..(Len(p)-1) : <<p[i], p[i+1]>> \in G.edge}
AreConnectedIn(m, n, G) ==
\E p \in Path(G) : (p[1] = m) /\ (p[Len(p)] = n)
=============================================================================
9.5 节说明了使用Integrate运算符描述混合系统，为了表达Integrate运算符，需要在 TLA+ 中表述微分等高级的数学运算。在此仅摘录极限的 TLA+ 表达。
邻域Nbhd(r, e) == {s \in Real: (r - e < s) /\ (s < r + e)}。
δ-ε 极限表示法求导数df(r)
\A e \in PosReal :
\E d \in PosReal :
\A s \in Nbhd(r,d) \ {r} : (f[s] - f[r]) / (s - r) \in Nbhd(df[r], e)
完整的微分方程表示以及Integrate运算符定义见原书。
TLA+ 的语法可以表示 BNF 语法，例如L & M == {s \o t : s \in L, t \in M}，L | M == L \cup M。更复杂的表达 BNF 语法的方法见原书。
为了尽量模拟真实世界中的内存，我们首先明确一个内存应当具有什么性质，并使用接口描述。本节描述一个多处理器、异步通信、每个处理器通过多个寄存器与内存交互的接口。
思考如何使用正确性描述这个接口的行为。我们规定对于单个处理器，内存的行为如同串行按照发起请求的顺序执行一样。处理器只有“读”操作会从内存返回值，我们以“读”操作为例更具体讨论如何描述内存的行为。
如果两个处理器对相同地址写入各自的值，然后进行有限或无限次的读操作，始终读到各自的值。这样的行为需要我们回应：某些优先顺序需要在无限长的行为中保持，还是仅在有限长的行为中保持？如果允许“有限长的行为中保持”，可以解释为内存对某个处理器的请求始终优先于另一个处理，因此发生了上述有限长的行为。但无论如何也不能解释无限长的行为，因此我们决定仅在有限长的行为中保持某些优先顺序。
另一个问题是：内存没有规定多个处理器之间的顺序，那么某个处理器能否使用另一个处理器未来的值？这自然也是不现实的。不使用未来的值也意味着在某一时刻等价的串行化顺序不因为未来的请求改变。
对于“与某种串行化等价”的性质，常常使用一个序列记录这种串行化的历史。我们使用opQ[p][i]表示处理器p的第i个操作，使用p、i表示opId，即
opId == {oiv \in [proc: Proc, idx: Nat]:
oiv.idx \in DOMAIN opQ[oiv.proc]}
系统的行为可以概括为IssueRequest(proc, req, reg)、RespondToRequest(proc, reg)、Internal三种，后两者应当用公平性对系统的特性进一步描述。其中RespondToRequest在产生结果后会对opQ进行就地修改，因此每个寄存器至多有一个对应的未完成的opQ中的操作。读操作会有一个source域记录读到数值的来源，这也由RespondToRequest进行修改。
在描述规范时，尽量把内部状态描述得可以通过单状态公式表达安全性。本节这个单状态公式就是Serializable。
为了固定多个处理器请求的相对串行顺序，使用opOrder集合进行记录。如果二元组属于该集合，则表示发生了二元组的两个元素具有相对顺序。Serializable使用opOrder描述系统性质：opOrder包含的元素个数只能增多；opQ[p]的顺序符合opOrder；读操作会读到相同地址的最后一次写入，或者初始值。最后一个性质表示为存在一个全序R满足：
\A oi \in opId:
("source" \in DOMAIN opQ[oi.proc][oi.idx]) =>
~(\E oj \in goodSource(oi): /* not exsit such oj
/\ <<oj, oi>> \in R
/\ (opQ[oi.proc][oi.idx].source /= InitWr) =>
(<<opQ[oi.proc][oi.idx].source, oj>> \in R) /* that issued after the source of oi
)
goodSource(oi)表示某个opId可能作为source域的所有请求。读操作的RespondToRequest会断定goodSource(oi)中存在符合opOrder'的请求作为响应。
接下来描述系统的活跃性，比较难的一点是表示内存最终能得到确定、唯一的串行化顺序。一种尝试是
\A oi, oj:
(oi \in opId) /\ (oj in opId) =>
((oi /= oj) =>
WF_<<...>>(/\ Internal
/\ (<<oi, oj>> \in opOrder') \/ (<<oj, oi>> \in opOrder'))
)
但是要注意该公式是时序逻辑公式，(oi \in opId) /\ (oj in opId)这种单状态公式只是描述初始状态，而不是每个状态。因此需要将其放入公平性之中应用到每个状态。
如果取消“某个处理器使用另一个处理器未来的值”的限制，也即某一时刻等价的串行化顺序可以因为未来的请求改变，就得到更简单的串行一致性内存。首先我们使opQ变为一个先入先出队列，“队列”的特性仍然保证了单个处理器需要满足的顺序关系，而新增的“可以出队”特性能在一定条件下获取未来的处理器值。
此外新增mem记录内存中的值。如果在读操作的opQ出队的同时，读操作返回的值是mem中地址对应的值，多个处理器就能通过mem通信，从而满足读操作结果的解释性。而为了表示获取未来的值这一特性，读操作返回的值不必是当前mem的值，如果它返回一个非当前值，则需要等待未来另一个处理器写入这个值时opQ才能出队。我们使用活跃性限定这种对未来的等待不能是毫无根据的无限等待。
上面提到的内存规范，有的能实现，有的需要过高的计算复杂度（例如在队列中搜索合法状态）才能实现，有的则不能实现。例如串行一致性内存在这种满足规范的场景下是无法实现的：多个处理器相互依赖未来值。
那些不能实现的规范往往是因为其不是状态机绑定的，也就是说某些实现中的公式会阻止一些步的发生。按照 8.9.2 节的解释，非状态机绑定是因为公平性描述的动作不能蕴含Next。但即便如此，有时为了简单的描述系统，我们还是会使用那些无法实现的规范。
以时钟为例，研究两个时钟组合而成的系统。如果我们把两个时钟的规范通过合取连接，经过化简后，“两时钟”系统会多出一个 next 步，表示两个时钟同时发生改变，这种规范叫做非交错规范。与其相对的交错规范指的是子组件不同时改变的规范。
如果我们想要“两时钟”系统是一个交错规范，可以通过下面两种方式之一解决：
让每个时钟的 next 动作显式合取另一个时钟的变量保持不变
依然合取原始的单个时钟的规范，但是再合取[][(x' = x) \/ (y' = y)]_<<x, y>>，其中x、y是两个时钟的小时值
在涉及组合多个规范的交错规范时，上一节的方式 1 就变得不合适了，因为让子组件去限制其他所有组件比较复杂。我们将方法 2 进行泛化：
[][\E k \in C: \A i \in C \ {k}: vi' = vi]_<<v>>
这个公式表示只有vk在改变，其他vi都不变。
回到时钟的例子。如果是多个时钟的组合而成的子系统，其中hr[k]表示第k个时钟显示的小时的数组。上面公式的v能否用hr替代呢？答案是不能。因为hr没有被限定定义域，因此可能在意料之外的定义域上有未预期的行为。解决这个问题有两种方式：
用hrfcn == [k \in Clock |-> hr[k]]代替v
合取一个运算符[]IsFcnOn(hr, Clock)，其中IsFcnOn(f, S) == f = [x \in S |-> f[x]]
另外，我们可以利用EXCEPT进一步简化组合规范N(k) == hrfcn' = [hrfcn EXCEPT ![k] = (hr[k] + 1) % 12]
FIFO 模块的自由变量是in、out两个Channel，以及Message消息集合。FIFO 由如下三个组件组合而成：Sender 影响in.val、in.rdy，Buffer 影响in.ack、q、out.val、out.rdy，Receiver 影响out.ack。我们可以注意到有的初始化公式是跨组件的：(in.ack = in.rdy) /\ (out.ack = out.rdy)。对于跨组件的公式有如下三种处理方法：
在公式涉及的所有组件的初始化公式中，重复地声明该公式
选择一个组件，在它的初始化公式中声明该公式
在所有组件的外部独立声明该公式。
在描述开系统时，需要使用后两种方法。
把上面的 FIFO 规范中的 Buffer 组件进行简化，用一个普通的buf序列代替，FIFO 就只剩下了 Sender 和 Receiver 两个组件，并且它们共同修改buf变量。这里的buf就是组件间的共享变量。我们尝试把整体的 FIFO 规范逆向分拆成两组件规范，Sender 和 Receiver 的步如下：
Sndr == \/ /\ buf' = Append(buf, ...)
/\ SCommunicate
/\ UNCHANGED r
\/ /\ SCompute
/\ UNCHANGED <<buf, r>>
Rcvr == \/ /\ buf /= <<>>
/\ buf' = Tail(buf)
/\ RCommunicate
/\ UNCHANGED s
\/ /\ RCompute
/\ UNCHANGED <<buf, s>>
两个组件的初始状态容易指定，但是Next步比较难分拆。我们使用NS、NR表示 Sender 和 Receiver 的 Next步
NS == Sndr \/ (sigma /\ (s' = s))
NR == Rcvr \/ (rho /\ (r' = r))
其中sigma和rho是仅关于共享变量buf的动作，更准确地说，是不由自己引起的buf变化。
我们尝试从分离的NS和NR合取得到组合系统的规范，即
[][NS]_<<buf, s>> /\ [][NR]_<<buf, r>> <=> [][Sndr \/ Rcvr]_<<buf, s, r>>
首先对上式左边进行化简：
[][
/\ Sndr \/ ((sigma /\ (s' = s)) \/ UNCHANGED <<buf, s>>)
/\ Rcvr \/ ((rho /\ (r' = r)) \/ UNCHANGED <<buf, r>>)
]
==
[][
\/ Sndr /\ Rcvr
\/ Sndr /\ ((rho /\ (r' = r)) \/ UNCHANGED <<buf, r>>)
\/ Rcvr /\ ((sigma /\ (s' = s)) \/ UNCHANGED <<buf, s>>)
\/ s' = s /\ r' = r /\ buf' = buf \* if (sigma /\ rho) => (buf' = buf)
\/ FALSE
\/ FALSE
\/ UNCHANGED <<buf, s, r>>
]
对于Sndr /\ ((rho /\ (r' = r)) \/ UNCHANGED <<buf, r>>)，可以看到Sndr的第二个子动作蕴含UNCHANGED <<buf, r>>，因此如果第一个子动作蕴含rho，该式即可化简为Sndr。对于Rcvr /\ ((sigma /\ (s' = s)) \/ UNCHANGED <<buf, s>>)也是同理。因此如果有下面三个假设：
\A d: (buf' = Append(buf, d)) => rho
(buf /= <<>>) /\ (buf' = Tail(buf)) => sigma
(sigma /\ rho) => (buf' = buf)
整个左边就可以化简为[][Sndr \/ Rcvr]_<<buf, s, r>>。即完成了从分离的NS和NR合取得到组合系统的规范。
上面三个假设只需要取合理的sigma和rho即可。一种（很强的）取法是
sigma == (buf /= <<>>) /\ (buf' = Tail(buf))
rho == \E d: (buf' = Append(buf, d))
另一种（更弱的）取法是sigma不变，rho == ~sigma。
上面即为一个交错规范。
接下来考虑一种非交错规范，同时允许SCompute和RCompute并保持buf不变。我们定义SSndr和RRcvr为不描述对方组件不变的公式，即
Sndr <=> SSndr /\ (r' = r)
Rcvr <=> RRcvr /\ (s' = s)
因此组合而成的系统的 next 步是Sndr \/ Rcvr \/ (SSndr /\ RRcvr /\ (buf' = buf))。我们又可以按照上面的方式定义NS、NR，并找到满足的sigma和rho。实际上sigma和rho与上面一致。
这种技巧可以推广到多个组件在共享变量的状态下进行组合：集合C由表示组件，共享变量是w，N_k第k个组件的Next步，动作mu_k表示由第k个组件以外的组件对w产生的所有改变，v_k是第k个组件的私有状态。下面是交错规范的共享状态组合法则：
如下的 4 个条件
(\A k \in C: v_k' = v_k) <=> (v' = v)
\A i, k \in C: N_k /\ (i /= k) => (v_i' = v_i)
\A i, k \in C: N_k /\ (w' = w) /\ (i /= k) => mu_i
(\A \in C: mu_k) <=> (w' = w)，表示在所有的组件以外，不存在改变w的组件，反之也成立
蕴含组件的合取等价于完整规范：
(\A k \in C: I_k /\ [][N_k \/ (mu_k /\ (v_k' = v_k))]_<<w, v_k>>)
<=>
(\A k \in C: I_k) /\ [][\E k \in C: N_k]_<<w, v>>
对于某些组合，一些动作可能会不得不由多个组件共同完成，于是我们可以把动作拆分为前提、多组件共有的子动作、组件私有状态的变化等更细粒度，分配给多个组件进行描述。显然“多组件共有的子动作”需要出现在每个组件的动作中。
交错规范与非交错规范
分离式状态与共享式状态：分离式状态即系统的状态可以完整分拆为，若干个单独由某组件影响的子状态变量。
联合动作与分离动作：联合动作规范是一种非交错规范，其中一些步会在多个组件上同时发生。不属于联合动作规范即为分离动作规范。
在对真实系统的抽象上，交错与否并没有限制。但是非交错规范通常不能蕴含交错规范，因此为了实现一个抽象规范，通常需要写交错规范。通过合取限制交错的公式，非交错规范很容易转化为交错规范。
“组合”就是为了把系统进行简化、分拆，但是联合动作阻止了这种分拆。一般而言，应当尽量减少联合动作，但是为了描述多组件的通信，为了把发送、接受两个动作抽象为一个动作，就需要联合动作以及增加辅助变量。
本章的组合表示了由组件的安全性构造系统的安全性，那么活跃性也可以由组件的活跃性构造出吗？按照前文的建议，活跃性的描述应当使用弱公平性和强公平性，首先要注意公平性的下标，选择私有变量或者全部变量正确描述系统。
接下来考虑如果组件是状态机绑定的，整个系统是否也是状态机绑定的。这个问题也没有通用答案，依然要使用 8.9.2 节的经验，如果公平性描述的动作是Next步的子动作，这个系统就是状态机绑定的。因此在交错规范中，如果组件的公平性描述的动作是整个系统Next步的子动作，系统是状态机绑定的。非交错规范的组件会相互影响，往往不是状态机绑定的，例如第 9 章芝诺式规范可以看作是有联合动作的组件相互影响从而不满足状态机绑定。
前文中我们介绍过使用\EE隐藏中间变量，对于组合而成的系统是否也可以这么做呢？按照定义，如果组件之间访问了共享变量，那么对各组件分别应用\EE，无法为共享变量建立跨组件的联系。如果（有限个）组件之间没有访问任何共享变量，对各组件隐藏变量就等价于对系统隐藏变量。
在交错规范中，如果组件 i 访问了其他组件 j 变量，但是这种访问仅是UNCHANGED v_j，那么也有上面的等价关系。
第 4 章介绍了开系统，本章我们可以从组合的角度进一步明确什么是开系统。前文中的规范是包含了系统与环境的闭系统，例如 FIFO 缓冲区规范中，缓冲区可以看作是系统，发送、接收方可以看作环境。开系统仅描述系统M本身，因此从组件的角度，似乎“环境E蕴含系统M”可以将开系统作为组件并与相应环境组合，形成一个闭系统规范。但这种描述太弱了，因为如果系统M主动破坏了规范导致E为假，E => M仍然成立。
为了限制上面的情况，引入新的运算符：E -+-> M表示
环境E蕴含系统M
对于任意自然数 n，如果行为的前 n 个状态满足E，那么前 n+1 个状态满足M。也即M不主动破坏了规范
对于一个闭系统规范，将其按照系统与环境拆分为组件，对同时与两者交互的公式分配给一方，以及提取不单独描述组件、仅描述组合而成的系统的公式（例如IsFcnOn），即可利用-+->转化为系统组件与环境组件。
接口微调指的是对高抽象层级的规范进行调整，得到低抽象层级的规范。
本节给出一个接口微调的例子。以前文时钟为基础，描述一个二进制序列表示小时值的时钟。对于一个二进制序列转十进制的函数BitArrayVal，除了用它来作为实例化的hr映射之外，为了避免该函数无意间将未定义的输入转化为了合法的小时值，还要确定函数的定义域。
HourVal(b) == IF b \in [(0..3) -> {0, 1}] THEN BitArrayVal(b)
ELSE 99 \* any value doesn't satisfy HC!Init
B == INSTANCE HourClock WITH hr <- HourVal(bits)
另一种不使用实例化的方式是，\EE hr: [](hr = HourVal(bits)) /\ HC
本节继续通过接口微调把一个信道转换为发送二进制值的信道。由于信道有发送-确认的机制，这里需要实例化两个信道，分别将可发送的数据指定为自然数和二进制，并通过一个中间缓冲区计算二进制到十进制的转化，以及在累积到若干二进制位后执行十进制信道的发送、确认步。
对于更通用场景而言，假如有一个高抽象层次的规范HSpec，想对它的接口进行调整实现一个更具体的规范LSpec，可以使用如下的公式：
LSpec == \EE h: IR /\ HSpec
其中h是HSpec的自由变量，IR模块将LSpec的l与h建立转化关系，l、h可能是长度不相等的元组。IR模块就起到了接口微调的作用。
对于HSpec与LSpec状态一一对应就能完成h与l的转换（例如 10.8.1），IR实际上只是[]表示的表达转换的单状态公式，这叫做数据微调。如果是多个状态才能决定h与l的转换（例如 10.8.2），IR就会表示得更加复杂。
开系统在进行接口微调时需要注意系统与环境两部分，依然以h与l为例，l的变化需要正确地归纳到系统或者环境中。
当开系统有活跃性描述时，例如 10.8.2，当l因为环境的不正确而阻塞时，h因为无法累积而阻塞，就会导致LSpec下系统正确、环境不正确影响了HSpec的活跃性，从而影响了HSpec的正确。为了避免这种情况，IR中也要包含合取子式描述LSpec的活跃性。
通常而言，写整体的规范或者组合而成的规范差别并不大。
]]>上一章的活跃性可以描述未来某时刻会发生某特性，但是更具有现实意义的是实时性，即描述在未来的某段时间里会发生。以时钟为例，如果我们想要描述hr在某段时间内会改变，首先要引入一个now变量表示时间，并明确其特性，例如hr相对于now是瞬时改变的吗？now的改变是否有最小或者最大粒度……
我们使用t变量记录hr两次改变间now的变化。动作是公式，因此具有真假值的含义，TNext == t' = IF HCnxt THEN 0 ELSE t + (now' - now)中HCnxt表达HCnxt步，因此本公式表示当HCnxt发生时t清零，当HCnxt不发生时t对经过的时间累加。
模块中可以继续定义子模块，在子模块上方的父模块部分对子模块可见。
很明显，now是一个单调增长的Real域变量，一个常常被忽略的问题时这种单调增长是否可以渐进于一个上界？本规范为了表示真实的时钟、排除有上界的now数列，可以使用\A r \in Real : WF_now(NowNext /\ (now' > r))表示。即
RTnow(v) == LET NowNext == /\ now' \in {r \in Real : r > now}
/\ UNCHANGED v
IN /\ now \in Real
/\ [][NowNext]_now
/\ \A r \in Real : WF_now(NowNext /\ (now' > r))
对于实时性的要求，一个更通用的描述是，动作<<A>>_v在连续（或累积）满足前提D秒到E秒的这段时间中一定发生。累计发生在实际中较少使用，因此我们只考虑连续E、D秒的情况。
RTBound(A, v, D, E) ==
LET TNext(t) == t' = IF <<A>>_v \/ ~(ENABLED <<A>>_v)'
THEN 0
ELSE t + (now' - now)
Timer(t) == (t = 0) /\ [][TNext(t)]_<<t, v, now>>
MaxTime(t) == [](t =< E)
MinTime(t) == [][A => D =< t]_v
IN \EE t : Timer(t) /\ MaxTime(t) /\ MinTime(t)
由定义可得，如果E =< Infinity，RTBound(A, v, D, E)蕴含WF_v(A)。当A定义为A1 \/ A2 \/ ...而Ai的满足前提不并发以及前提的不满足只能通过运行该动作时，有重言式
RTBound(A, v, D, E) = RTBound(A1, v, D, E) /\ RTBound(A2, v, D, E) /\ ...
前面两节定义的RTnow和RTBound可以作为通用的描述实时性的模块，例如内存可以将RTBound(A, v, D, E)的A定义为(ctl[p] /= "rdy") /\ (ctl'[p] = "rdy")，即描述处理器p恢复空闲的时间。
对于内存的实现——直写式缓存内存而言，如果它可以增加实时性的描述并蕴含上面的实时内存，就可以认为它是实时性内存的实现。然而目前的直写式缓存并不能蕴含实时内存，这是因为没有指明调度算法，有的处理器可能始终抢占memQ使得其他处理器资源始终受限。这可以对影响memQ的动作添加 round-robin 等调度算法解决。
具体而言，RdMiss和DoWr会添加消息到memQ上从而抢占其他处理器，所以这两个动作要添加 round-robin 作为前提，并更新lastP记录行动的上次处理器。round-robin 具体条件如下：
position(p) == CHOOSE i \in 1..N : p = (lastP + i) % N
canGoNext(p) == \A q \in Proc : (position(q) < position(p)) => ~ENABLED(RdMiss(q) \/ DoWr(q))
一个now无限增长但渐进上界的行为叫做“芝诺式的”。公式\A r \in Real : WF_now(NowNext /\ (now' > r))阻止了芝诺式行为的发生，这个公式叫做NZ（Non-Zeno）。在仅允许芝诺式行为的系统中，NZ始终为FALSE。
仅允许芝诺式行为的规范叫做芝诺式规范，例如RTBound(A, v, D, E)中D > E，意味着now不断趋近于E。芝诺式规范的形式化定义是：存在有限的行为满足规范的安全性部分，但是不存在无限的行为同时满足安全性和NZ。非芝诺式规范等价于状态机绑定的规范。芝诺式规范往往是因为实时性条件限制了一些系统行为的发生，这类似于非状态机闭包。
非芝诺式规范更有用，一般而言，由下面三类公式合取的规范是非芝诺式的：
Init /\ [][Next]_varsRTnow(vars)RTBound(Ai, vars, Di, Ei)公式，其中
0 =< Di =< Ei =< InfinityAi是Next的子动作Ai描述更具体实现的规范容易满足上面的要求，描述更抽象的规范往往找不到合适的Ai满足Ai是Next的子动作。
TLA+ 将系统描述成了时间上离散的状态，但是真实世界中的系统往往有物理量需要连续时间，这叫做混合系统规范。混合系统规范可以通过在离散的时间点上应用积分运算符Integrate计算两个状态间的变化描述相关变量。具体而言，所有离散的变量形成元组vd，连续变量（除了now）形成元组vc，RTnow通过如下的公式替代
/\ now' \in {r \in Real: r > now}
/\ vc' = Integrate(D, now, now', vc)
/\ UNCHANGED vd
其中D是微分方程。这个公式的含义是，在公式运行的瞬间vd不变，通过积分计算vc的新状态。
实时性可以看作是比活跃性更强的描述，在简单系统中可以取代活跃性。通常而言，只使用RTnow和RTBound就能满足规范对实时性的描述和证明。
本章开始，我们将会更多地判断系统在“时间段”上的命题。之前的规范涉及了简单的时序逻辑，我们继续沿用那些符号并进行扩展。
在此引入一些术语简化表达：单状态公式表示只涉及一个状态的公式，动作表示只涉及一次状态转移的公式。
系统的行为定义为无限个状态通过状态转移形成的序列，时序逻辑公式F为系统的行为sigma判定真假值，这记为sigma |= F。从定义有|=对/\、~、\E、\A有分配律。接下来我们定义如何判断|=的真假值。
对于单状态公式，系统行为的第一个状态的真假定义了|=的真假
对于单状态公式F，F在行为的每个状态都为真，sigma |= []F才为真
对于动作N和状态公式v，行为的每一次状态转移都满足[N]_v，sigma |= [][N]_v才为真
上述三种公式在前面章节都已经出现，接下来我们对他们的含义进行扩展。
首先是将含义扩展到动作（但按照时序逻辑公式的定义，动作并不是时序逻辑公式，因为它不涉及无限个状态）。对于动作A，sigma |= A为真表示系统的第一个状态转移满足动作A，sigma |= []A表示系统的每个状态转移满足动作A。依照这种方式，我们也可以将含义扩展到一般的时序逻辑公式。
接下来是定义[]运算符。将系统状态转移序列的任意一个状态视作“第一个状态”，也即截断前几个状态，如果任意截断后状态转移序列都满足时序逻辑公式F，则记为系统的行为满足[]F。因此[]运算符实际上表达了从某状态（默认为初始状态）以后始终满足的含义。
在 2.2 节中，为了描述过于频繁的观察，我们允许系统在相邻状态中所有变量都不改变，而这会使得有些时序逻辑公式为假。为了解决这个问题，TLA+ 仅允许表达“允许所有变量都不改变”的时序逻辑公式。通常而言，单状态公式、[][N]_v以及它们通过[]运算符和布尔运算符组合而成的公式都是 TLA+ 允许表达的。
接下来引入五种记号简化表达：
<>F表示~[]~F，即F不总是假的，即<>表达了从某状态以后至少一次满足的含义。
F ~> G表示[](F => <>G)，即F为真之后，G会在某时为真。
<><<A>>_v表示~[][~A]_v，即不是每一步都是(~A) \/ (v' = v)步，即某一步会是A /\ (v' /= v)步。我们也可以视作<<A>>_v == A /\ (v' /= v)（但这不是时序逻辑公式，因为它只描述一次状态转移），并结合<>的含义记忆。
[]<>F即在任意时刻以后，F会为真。这也意味着F无穷次为真。
<>[]F表示存在某个时刻，F在那以后一直为真。
[]和<>的优先级比布尔运算符高，~>的优先级比合取、析取低。
时序逻辑中的重言式更加复杂，有的重言式可以通过含义直接判断，有的则需要借助一些转化的技巧。
对偶重言式是指，将时序逻辑公式的[]与<>、/\与\/相互替换，并反转蕴含的方向，就能得到一组对偶重言式。
需要注意<<A>>_v需要与<>组合才是时序逻辑公式，有些重言式会使得<<A>>_v变成独立的谓词，这是不合法的。例如
[]<>(<<A>>_v \/ <<B>>_v) <=> ([]<><<A>>_v) \/ ([]<><<B>>_v)
其中(<<A>>_v \/ <<B>>_v)没有与<>组合，需要转化为<<A \/ B>>_v才是合法的公式。
时序逻辑的证明法则可以沿用命题逻辑的证明法则，除此之外
时序逻辑有自己的证明法则：
泛化法则：对于时序逻辑命题F，如果所有的行为都有F，那么所有的行为都有[]F。这可以由 8.1 节对[]的定义和行为通过截断关系相互转化得到
蕴含的泛化法则：对于时序逻辑命题F、G，如果所有的行为都有F => G，那么所有的行为都有[]F => []G
命题逻辑的法则对应一个重言式，而时序逻辑不是。这是因为时序逻辑是对于系统的行为，即无限长的状态序列进行描述，重言式在语义上是命题逻辑，不能描述更高级的时序逻辑
F => []F是重言式。我们可以令F为状态公式，sigma的第一个状态使F为真，后续状态使F为假，容易验证sigma |= (F => []F)并不为真。系统有安全性和活跃性两种特性，分别表示“某些特性总是满足”以及“某些特性在时间段上满足”。本书的第一部分说明 TLA+ 如何表达安全性，而在了解了[]和<>运算符之后，我们就可以表达活跃性了。对于第二章的时钟，一个永远运行的时钟可以表达为[]<><<HCnxt>>_hr。
但是在有些情况下，活跃性还需要前提条件。第三章的异步接口
Rcv == /\ chan.rdy /= chan.ack
/\ chan' = [chan EXCEPT !.ack = 1 - @]
为了表示发送的值总会被接受，前提是存在发送的值，也即chan.rdy /= chan.ack。TLA+ 通过ENABLED关键字描述某个动作的前提。因此“异步接口发送值总会被接受”可以描述为[](ENABLED <<Rcv>>_chan => <><<Rcv>>_chan)或[](ENABLED Rcv => <><<Rcv>>_chan)或ENABLED Rcv ~> <><<Rcv>>_chan。
弱公平性WF_v(A)定义为[]([]ENABLED <<A>>_v => <><<A>>_v)，其含义是如果动作<<A>>_v在任意时刻 t 后都能进入永远满足前提的状态，那么<<A>>_v在 t 后必将发生。弱公平性与以下两种定义等价：
[]<>(~ENABLED <<A>>_v) \/ []<><<A>>_v，即<<A>>_v在任意时刻之后都有不满足前提条件的时候，或者在任意时刻后<<A>>_v总会发生
<>[](ENABLED <<A>>_v) => []<><<A>>_v，即<<A>>_v在某时刻后会永远满足前提，则在任意时刻后<<A>>_v总会发生
定义了弱公平性后，我们发现“发送的值总会被接受”[](ENABLED <<Rcv>>_chan => <><<Rcv>>_chan)与弱公平性[]([]ENABLED <<Rcv>>_chan => <><<Rcv>>_chan)是不同的。如果我们能证明在异步接口的规范下两者恒等，就能用弱公平性简化表达。
这里由异步接口的规范可得：如果<<Rcv>>_chan的前提满足，即发送了一个值后，或者发生<<Rcv>>_chan从而接受这个值；或者这个值永不被接受，也就是[](ENABLED <<Rcv>>_chan)。这可以推出两者恒等。即下面是一个重言式，表示满足前件后“发送的值总会被接受”这种叙述与弱公平性等价
[](E => []E \/ <>A) => ([](E => <>A) <=> []([]E => <>A))
公式中E表示动作A的前提，A表示弱公平性描述的动作。
我们希望限定第五章的内存模型能够“对发出的请求最终会得到回复”。其中MemoryInterface模块只给出了Reply操作符接口的定义，没有具体公式的实现，因此ENABLED关键字不能判断何时满足前提，这需要我们增加一个假设
ASSUME \A p, r, miOld : \E miNew : Reply(p, r, miOld, miNew)
请求的发送到回复需要经历两个逻辑上连续的动作，因此活跃性可以表达为
Liveness == \A p \in Proc : WF_vars(Do(p)) /\ WF_vars(Rsp(p))
其中vars表示系统的所有变量。
上面的公式会让我们思考，是否WF_v(A) /\ WF_v(B)与WF_v(A \/ B)是等价的。一般而言它们不等价，但在内存的例子中，由于Do(p)和Rsp(p)的一者满足前提时，另一者前提不会被满足，直到前者被运行，它们就等价。这是一条通用的定理，具体证明见原书。
上一小节的定理引出了弱公平性合取法则：对于动作A1，……，An，如果所有的Ai，Aj都满足一者满足前提时，另一者前提不会被满足，直到前者被运行。那么WF_v(A1) /\ ... /\ WF_v(An)等价于WF_v(A1 \/ ... \/ An)。
考虑到合取与析取与全称量词、存在量词对应，上面的弱公平性合取法则也可以表示为量词形式。
强公平性SF_v(A)有以下两种等价定义：
<>[](~ENABLED <<A>>_v) \/ []<><<A>>_v，即<<A>>_v在某时刻后保持不能满足前提，或者<<A>>_v发生无数次
[]<>ENABLED <<A>>_v => []<><<A>>_v，即如果<<A>>_v无数次满足前提，那么<<A>>_v发生无数次
其中第二种定义与弱公平性<>[](ENABLED <<A>>_v) => []<><<A>>_v类似。由于<>[](ENABLED <<A>>_v)蕴含<>[](~ENABLED <<A>>_v)，满足强公平性的系统一定满足弱公平性。在下面的条件下，强公平性与弱公平性等价：
[]<>(~ENABLED <<A>>_v) => <>[](~ENABLED<<A>>_v) \/ []<><<A>>_v
一种常见的满足上式的条件是：动作的不满足前提仅因为动作的运行会取消自身的前提，例如第三章异步接口的Rcv后（如果没有其他动作）就不满足下次Rcv的前提。另一种满足上式的表述是：动作一旦满足前提，在它运行前会保持满足前提的状态，运行后则不满足前提。
强公平性的合取法则、量词形式的合取法则与弱公平性一致。
强公平性更难实现，也在规范中更少出现。在强、弱公平性等价的时候，最好表述弱公平性。此外应尽量使用强、弱公平性而不是原始的时序逻辑公式去描述系统。
直写式缓存与 8.4 节的异步接口类似，想描述“每个请求都将收到响应”，首先要尝试按照 8.4 节的等价关系转化为弱公平性。假设能满足转化，这意味着Next动作中与“请求-响应”相关的析取子式具有一定的公平性，而这些动作子式究竟应该使用弱公平性还是强公平性又需要我们仔细讨论。因此我们现在有两个问题：
“每个请求都将收到响应”能否转化成弱公平性
这种公平性是否需要加强为强公平性
首先考虑第一个问题。直写式缓存的读、写请求，这有多种方式满足“请求-响应”流程，例如Req(p)、DoRd(p)、Rsp(p)。这些动作可以通过验证 8.4 节的等价关系转化为弱公平性。但是有的动作并不是直接符合 8.4 节等价关系。例如DoRd(p)表示读请求在缓存命中时的响应，它的满足前提可能会被Evict(p, a)清理缓存所破坏，似乎不满足“动作的前提满足后，要么在未来运行该动作，要么该前提始终保持满足”的定义。
我们进一步考虑Evict(p, a)之后发生了什么。在Evict(p, a)破坏后，RdMiss(p)的前提被满足，如果RdMiss(p)以及后续动作符合 8.4 节的等价关系以及弱一致性，并在一连串动作后使得DoRd(p)的前提重新被满足，且不会被其他动作破坏，那么从更大的时间跨度上可以得到：DoRd(p)的前提满足后，要么该前提一直满足，要么DoRd(p)在未来会运行。从而能转换成弱公平性。
而RdMiss(p)与DoWr(p)的前提需要消息队列不满，因此它们对于处理器p的前提满足时，可能由于另一个处理器q的这两种动作使前提不满足。也就是说，它们的前提满足不能保持始终为真。为了描述“每个请求都将收到响应”的特性，这些动作需要强公平性。这也就是问题二。
因此直写式缓存的活跃性表示为
/\ \A p \in Proc: /\ WF_vars(Rsp(p))) /\ WF_vars(DoRd(p))
/\ SF_vars(RdMiss(p)) /\ SF_vars(DoWr(p))
/\ WF_vars(MemQWr) /\ WF_vars(MemQRd)
考虑到MemQWr在全是写请求以及队列未满的时候无需运行，我们也可以通过合取这个限制条件进一步弱化描述。
在时序逻辑下，命题逻辑的量词表示所限定的变量在所有状态下保持不变。如果想要描述随着状态改变而改变的变量，应该使用时序逻辑量词\EE和\AA。
CHOOSE运算符不能扩展到时序逻辑中。
时序逻辑公式既可以表达对系统的描述，也可以表达要证明的性质。一般而言，通过弱公平性和强公平性表示描述，通过基础的运算符表达要证明的性质。规范的完整形式如下：
Init /\ [][Next]_vars /\ Liveness
在表达不同抽象层级的规范时，常常使用\E、\EE隐藏一些中间变量。
描述系统的活跃性时应当尽量使用弱公平性和强公平性，而不是基本的时序逻辑公式，这是因为在构造时序逻辑公式时容易出错。这种出错常常会限制Init或[][Next]_vars中的一些状态或动作不能发生，因此使得规范意外地少描述了系统。一个不影响Init和[][Next]_vars的活跃性被称为状态机绑定的。
我们定义A是Next的子动作为：如果所有的A步都是Next步，或者A蕴含Next。在大多数情况下，公平性描述的动作应该是Next的子动作，这样就不会破坏状态机绑定。在有些复杂情况下，确实存在一些系统不能通过弱一致性和强一致性描述活跃性。这将在 11.2 节描述。
可以把活跃性视作概率意义，例如对于一对状态机绑定的Spec和[]<><<A>>_v，Spec所描述的系统总有可能发生无穷多次<<A>>_v。在使用 TLA+ 表示规范时，要注意真实系统的行为符不符合规范，以及规范的公平性足够由真实系统的行为推出。
5.8 节介绍了规范 A 实现规范 B 需要证明规范 A 蕴含了这种实例化的规范 B。在增加了活跃性后，实例化时的变量映射能否对弱、强公平性分配呢，也即：
由<<vars0>>实例化的<<vars>>，是否满足规范 B 的WF_v(A)等于规范 A 实例化的WF_v0(A0)呢？
答案是不等于，因为其他的运算符满足分配律，但ENABLED关键字不满足分配律。例如实例化为两个形式参数分配了同一个实际参数，接口中的前提就会产生干扰。
因此，在规范中出现实例化映射和公平性时，需要我们还原成时序逻辑公式并对ENABLED运算符按如下规则手动计算：
对于任意动作，ENABLED(A \/ B) <=> (ENABLED A) \/ (ENABLED B)
对于单状态公式P和动作A，ENABLED(P /\ A) <=> P /\ (ENABLED A)
对于动作A和B，如果A和B不同时更改同一个变量，ENABLED(A /\ B) <=> (ENABLED A) /\ (ENABLED B)
对于任意变量x和单状态的表达式exp，ENABLED(x' = exp) <=> TRUE，ENABLED(x \in exp) <=> (exp /= {})
实际应用中，安全性比活跃性更重要。
时序逻辑表达方法众多，可读性差，最好按照统一的方法写时序逻辑公式。
]]>集合有两个更高级的运算符：
交集UNION { {1, 2}, {2, 3} } = {1, 2, 3}
求子集（幂集）SUBSET {1, 2} = { {}, {1}, {2}, {1, 2} }
描述某种类型且元素满足某种公式的集合有两种方法，以奇数为例：{x \in Nat : x % 2 = 1}和{2 * n + 1 : n \in Nat}。
FiniteSets模块定义了两种新的运算符：
Cardinality(S)在S是有限集时返回元素的个数。
IsFiniteSet(S)判断S是有限集。
在 TLA+ 的集合定义下，如何避免罗素悖论？TLA+ 的方式是限制自身的表达能力，不能表达其元素与“所有集合”一一对应的集合。
TLA+ 没有类型系统，因此不能检查3 / "abc"等无意义的表达式。可以认为这些表达式具有一个由表达式唯一复现的、不确定的返回值。
TLA+ 要求递归函数有特殊的定义方法。下面的直观的递归定义阶乘函数是错误的：
fact == [n \in Nat |-> IF n = 0 THEN 1 ELSE n * fact[n - 1]]
原因是在解析右侧的表达式时，fact标识符还没有定义。
第五章中说明递归定义的语法是f[x \in S] == e，这实际上是f == CHOOSE f: f = [x \in S |-> e]。TLA+ 通过对CHOOSE关键字的语法解析完成递归函数定义。同样，如果不存在合法的CHOOSE，例如无意义的表达式或者表达式与要定义的函数有逻辑冲突，递归函数将会定义为某个不确定的值。
有些递归函数表达为同时依赖多个函数，例如 f、g 的计算同时依赖 f、g。这可以通过定义一个记录并通过record.f和record.g访问解决。
虽然 TLA+ 支持递归定义，但是应当注意运用已提供的运算符，这样效率更高。例如不要使用递归重复定义Head(s)。
函数和运算符有如下区别：
函数是一个语法完整的公式，运算符不是。具体而言，function \in S、function[x] \in S、operator(x) \in S都是合法的，但operator \in S有语法错误。
函数有定义域，但运算符没有。有的运算符（例如Tail(s)）的定义域太大而不能在 TLA+ 下表达，参见 6.1 节。
Cardinality运算符可以定义为：
Cardinality(S) ==
LET CS[T \in SUBSET S] ==
IF T = {} THEN 0
ELSE 1 + CS[T \ {CHOOSE x: x \in T}]
IN CS[S]
运算符可以将另一个运算符作为参数。
中缀关系只能由运算符定义。
按照前文定义的方式正确定义函数，奇怪的定义方法往往有潜在问题。
CHOOSE 运算符CHOOSE 运算符在无法“选出”一个符合要求的元素时会返回不确定的值，但相同的CHOOSE公式是可复现的。
在实现前、在设计阶段发现错误
精确、清晰地描述系统
应用工具自动化检查
写规范的主要目的是暴露错误，TLA+ 擅长处理并发场景，因此应当主要用作暴露并发错误。
使用什么粒度描述系统通常需要经验的积累，这里有一个经验：
在某种粒度上，系统的状态转移如果是可交换的，并总能将步1与步2交换到相邻位置，那么就可以把步1和步2组合为一个步。
再次强调，写规范的主要目的是暴露错误，如果内存布局、数据结构等信息并不会出错，就无须在规范中指明。例如第五章使用Send运算符描述系统的状态转移，没有深入到系统如何实现Send之中。
在此总结一下写规范的步骤：
选择要描述的系统组件和抽象层级
选择变量表示系统状态，定义不变量、初始状态，此时可能需要定义额外的常量和假设
描述状态转移，尽量做到紧凑、容易阅读
描述时序逻辑特性，这会在第八章介绍
描述系统的性质作为定理
指定变量的新值时，要注意最好使用v1' = exp或v2' \in exp的合取形式，而且exp中不能出现不确定的'变量。
要留意类型不变量中对变量类型做出的限制，其他公式是不知道的。例如
action1 == (n' > 7) /\ ...
action2 == (n' <= 6) /\ ...
Next == (n \in Nat) /\ (action1 \/ action2)
不要遗漏这里的n \in Nat。
以一个获取键盘输入的规范为例，要考虑到同时按下多个键的情况。规范过于抽象会忽视真实系统的一些状态。
TLA+ 不能判断两个不同类型值不相等。
量词提到子公式的外层能提升可读性。
'的对象op(a) == x + a
对于上面运算符
op(y)' = (x + y)' = x' + y'
op(y') = x + y'
而op'(y)有语法错误，'只能应用在表达式上。
注释不要通过/\ FALSE等表达写成规范的一部分。
最好在实现系统之前明确规范。规范可以先仅描述部分特性，即使这样也可以利用工具检查一些错误。
]]>