【论文研读】-Thread-level transactional memory(TTM)

摘要

本文介绍了线程级事务内存 (TTM)，这是一种内存系统接口，可将事务的语义（原子性、一致性和隔离性）与实现分开。通过使事务成为线程级抽象，TTM 允许使用高级软件、低级软件和专用硬件的不同组合来实现。 TTM 跟踪事务的读取和写入集，并在线程的虚拟地址空间中创建“前映像”日志。我们使用全系统模拟评估四种 TTM 实现——广播和目录一致性乘以两种不同的事务中止机制。与以前的事务性内存系统一样，TTM 实现与基于锁的同步具有竞争力或更好。 TTM 缓存前后图像的能力既支持大事务，又支持成功提交时的低内存带宽和中止时的快速回滚。

引言

随着人们对电脑性能方面需求越来越大，目前的多线程事务机制无法满足人们日益增长的需要。主要面对的是多线程事务的正确性和高性能两个方面的冲突。在简化的层面上，DBMS 使用并发控制算法实现并行执行（同时保留 ACID 属性），该算法跟踪事务的读写集（分别为读取和写入的项目），检测冲突（一个事务的写集与另一个事务的读或写集之间的重叠） ，并采取适当的行动（提交一个非冲突事务，但让一个有冲突的事务等待或中止）。

事务内存系统扩展了事务概念以促进通用多线程编程。这些事务与 DBMS 事务显着不同，它们针对相对较短的任意内存操作序列，并且仅提供前三个 ACID 属性——原子性、一致性和隔离性，但不提供持久性。

我们的论点是事务性内存支持应该以虚拟内存为模型。

• 首先，事务应该是线程级的抽象：定义在可缓存虚拟地址的协作线程和线程的用户可见寄存器状态之间。
• 其次，所有线程都应该看到一个独立于特定硬件实现的接口；性能可能因实现而异，但不是高级功能。
• 第三，实现应该使用高级软件、低级软件和硬件的明智组合（类似于虚拟内存实现：分页策略、TLB/页表代码和 TLB/页表遍历硬件，分别）。这意味着完整的事务支持可用于用户级线程，并且可能是高级操作系统线程，但不是内核。
• 最后，我们推测（但不在本文中探讨）分层接口有助于异常处理、性能调整和扩展（例如，事务性 I/O）。

简单介绍一下各个章节的主要内容
第二部分： 呈现线程级事务内存 (TTM) 接口。高级接口允许线程开始、提交或中止事务。 TTM 为成功的事务提供 ACI 属性，并检测冲突事务何时需要中止。在中止时，TTM 系统可以透明地将线程的部分或全部内存状态恢复到事务前值。然后系统调用用户级软件中止处理程序，该处理程序使用“前映像”日志恢复剩余的内存状态。日志——分配在线程的虚拟地址空间中，但仅在中止处理程序中定义——包含任何未恢复内存块的（虚拟）地址和预写值。 TTM 系统保持未提交写入的隔离，直到中止处理程序恢复前映像。
第三部分 ：提供了四个线程级事务的示例实现。 (1) 与之前的工作一样，他们增加了 L1 和 L2 缓存以跟踪读取和写入集，并扩展写入无效一致性以检测冲突。 (2)它们允许事务替换其读写集中的块，同时仍然检测（潜在的）与广播协议的布隆过滤器[4]或目录协议的目录的冲突。允许事务中的缓存容量和冲突未命中将程序员从大多数硬件限制中解脱出来。 (3) 在第一次存储到块时，它们将预写值附加到可缓存虚拟内存中的日志中。由于可以缓存旧值和新值，因此提交和中止通常都很快。 (4) 对于处理中止，我们评估默认软件处理程序并使用硬件引擎“遍历”日志

第四部分： 使用全系统仿真来评估 TTM 实现。结果表明，TTM 系统的性能与使用锁一样好或更好，并且大多数事务都很小。使用微基准和 SPLASH-2 基准的实验证明了缓存日志和更新值的重要性，但是质疑拥有重量级中止硬件的效用

本文做出了四个主要贡献：

• (1) TTM 是一种事务性内存接口，可以实现具有不同硬件复杂性的替代实现；
• (2)TTM 将新旧值都存储在可缓存的虚拟内存中，允许多个事务在不更新主内存的情况下写入一个块（例如，多次迭代访问缓存中的工作队列）；
• (3) TTM 的日志在线程虚拟地址空间，允许事务独立于缓存硬件限制；
• (4) 我们证明在（库）软件中进行中止处理可以减少硬件并且仍然表现良好

TTM接口

在行为层面，TTM 为成功的交易提供原子性、连贯性和隔离性，并检测并解决冲突事务。在运营层面，TTM 执行以下操作：

• 1、在事务开始时，TTM 通过为线程的体系结构寄存器状态的检查点分配空间来初始化线程的日志。尽管空间是立即分配的，但硬件直到稍后才需要将检查点写入日志。这类似于 SPARC 处理器，它在过程调用上分配堆栈帧，但尽可能长时间地推迟溢出寄存器窗口 [45].
• 2、对于事务期间的读写操作，TTM 分别更新线程的读写集。 TTM 的抽象模型是每个线程为内存的每个字维护两个位——指示读、写或两者兼而有之。实现可以自由地保守地实现这一点。例如，大多数实现将在缓存块上维护读写集，而不是单词粒度。一些实现可能会更粗略地隔离大型事务，就像一个长 DBMS 事务可能会从行级锁升级到页级或表级锁 [9].
• 3、TTM 还必须监视其他线程的读取和写入，以检测冲突事务。实现可以通过停止事务、避免或检测死锁或中止事务来解决冲突。
• 4、对于事务期间的写入，TTM 还确保已记录虚拟地址和“前映像”。与上面的寄存器检查点一样，实现必须立即分配日志空间，但可能会延迟更新日志条目。
• 5、提交时，TTM 会重置线程的日志和读写集。因为日志更新可以延迟，一些实现可能永远不会在短事务期间实际写入日志（很像 SPARC 寄存器窗口消除了大多数寄存器溢出）。
• 6、在中止时，TTM 实现可以透明地将状态恢复到某些或所有修改块的交易前值。然后，软件中止处理程序使用日志撤消任何剩余的写入并（通常）重新启动事务（通过调用与实现相关的层）。因为日志驻留在不可缓存的（虚拟）内存中，所以对于大多数中止日志条目很可能是缓存命中。 TTM 实现必须继续强制隔离修改过的块——通过将它们保存在写集中——直到恢复前事务状态。
• 7、为了促进软件组合，在事务中开始的事务被包含在外部事务中

更具体地说，下图 突出显示了 TTM 接口的三层。顶部单元格显示大多数程序员使用的唯一界面：开始、提交和中止事务。中间的单元格呈现来自系统/库接口的选定函数，这些函数维持线程级事务。函数初始化一个线程以使用事务（例如，为日志分配连续的虚拟地址空间）并注册一个中止处理程序。最后，底部单元格突出显示了一个低级将中止处理程序的与机器无关的方面与特定于机器的方面隔离开来的接口。我们将这种分离建模在虚拟内存系统和设备驱动程序中使用的分离上。

TTM 机制

TTM 指示接口，而不是实现。这使得一系列 TTM 系统成为可能：（几乎）所有硬件实现最高性能，所有软件实现早期验收和开发，最重要的是，硬件和软件的明智组合以平衡价格和性能。所有 TTM 实现必须支持三个基本机制：日志记录、隔离和提交/中止。所有三种机制都可以在软件、硬件或各种组合中实现。

记录： 事务记录可以在软件中实现，使用编译器或可执行编辑工具添加代码注释，将前图像显式存储到日志 [23, 24]。硬件实现可以直接写入日志，就像某些过程调用指令将返回的 PC 写入堆栈一样。更具侵略性的硬件实现可能会通过将日志写入特殊缓冲区（如一些容错系统 [41]）来处理小事务的常见情况，在溢出时将缓冲区溢出到（可缓存的）虚拟地址空间。这样的实现可能需要对事务中止（见下文）的硬件支持，以便在写入日志时处理异常。
隔离： 事务隔离检测两个（或更多）事务冲突时。隔离类似于硬件和软件分布式共享内存系统使用的细粒度访问控制机制 。软件实现可以使用代码注释来检查和更新软件数据结构。硬件实现可以向内存添加额外的状态。理论和/或扩展缓存一致性协议以实现更高的性能。大多数实现将针对常见的小型事务进行优化，为较大的事务提供较慢的支持。
提交/中止： 事务提交涉及重置日志（简单）和用于保持隔离的读写集（取决于实现，以上）。中止从根本上来说更复杂，因为它们必须从日志中恢复之前的图像。基于任何日志的中止方案必须能够在处理日志时处理异常（例如，页面错误和 TLB 未命中）。 TTM 通过定义一个在线程的执行上下文中运行的软件日志处理程序来解决这个问题，允许它不仅容忍缓存和 TLB 未命中，而且容忍一些页面错误（例如，日志页面）。更具侵略性的实现可以使用硬件来加速常见的无异常情况。

讨论

TTM 定义了在虚拟内存上运行的用户级线程之间的事务。虽然硬件可能加速性能，逻辑语义必须与用户级执行一致。因此，TTM 系统必须在正常执行和中止处理期间容忍软件错误，例如 TLB 未命中和页面错误。类似地，用户级线程的事务不能对操作系统产生不利影响，操作系统必须可以自由地页出或上下文切换线程。当此类事件发生时，TTM 系统可能会中止一个或多个事务或序列化它们的执行以确保正确执行。例如，如果一个实现不能跨分页事件保存和恢复隔离元状态，它可能会中止页面输入上的所有当前事务。

四种TTM实现

本节描述了四个示例 TTM 实现。尽管它们没有展示所有可能的实现，但它们说明了 TTM 接口提供的一些灵活性。

• 3.1节描述了包括日志在内的通用框架；
• 3.2节描述了基于广播（Bcast）和基于目录（Dir）一致性的两种可选隔离方案；
• 3.3 节描述了两种使用更多（Heavy）或更少（Light）硬件的事务中止机制。叉积产生四种实现：
  • TTM-Bcast-Heavy、
  • TTM-Bcast-Light、
  • TTM-Dir-Heavy 和
  • TTM-Dir-Light

常见机制，包括日志记录

四个 TTM 实现共享一个共同的框架；然而，未来的 TTM 实现不限于此设计点。基本系统是一个缓存一致的共享内存多处理器。每个处理器都有专用的 L1 和 L2 高速缓存，它们是回写、写入分配和设置关联的。一致性通过写入无效协议维护，该协议允许否定确认（nack）并使用修改（M）、共享（S）和无效（I）MOESI 状态。

为了支持 TTM，每个处理器扩展了一个 TTM 模式位、嵌套计数和日志指针。 TTM嵌套计数允许第一个外部事务包含后续的内部事务。处理器还执行用户级指令开始、提交和中止，以直接支持 TTM 接口。指令开始设置 TTM 模式位并增加嵌套计数。如果处理器之前未处于 TTM 模式，它会将线程的体系结构寄存器检查点到影子寄存器文件。虽然逻辑上是日志的一部分，但延迟更新语义有效地允许寄存器无限期地保留在卷影副本中。指令提交递减 TTL 嵌套计数。如果现在为零，处理器将重置 TTM 模式，重置隔离状态，并重置日志指针。指令中止触发与检测到的冲突相同的中止操作。确切的操作因替代实现而异。中止完成后，TTM 模式位、嵌套计数和日志指针被复位。

日志记录在缓存块粒度（64 字节）上完成。在第一次存储到缓存块（使用 Wbits 检测，如下所述）时，从 L1 缓存读取整个块，然后连同虚拟地址一起写入日志.单个条目 micro-TLB 有效地预翻译了日志的虚拟地址。小型硬件日志缓冲区减少了 L1 缓存端口的争用并隐藏了任何 L1 缓存未命中延迟。

最后，当两个事务发生冲突时，一个实现可能会停止（冒死锁风险）或中止（冒活锁风险）至少一个事务。这些 TTM 实现使 TLR 的分布式时间戳方法适应逻辑顺序事务 [33]。代替 TLR 的事务计数，他们使用每个处理器、松散同步的物理时钟来生成时间戳值，类似于 SafeyNet [41] 中的检查点时钟。在事务开始时，处理器记录时间戳时钟的当前值并将该时间戳附加到作为事务一部分的所有内存请求中。当处理器接收到冲突请求时，它将请求的时间戳与其自己的时间戳进行比较。来自逻辑上较晚事务的请求被停止（使用nacks）；来自逻辑上较早事务的请求会导致处理器中止自己的事务。请注意，当事务中止并重新启动时，它会继续使用原始时间戳。这确保了——即使存在许多冲突——一个事务最终将成为逻辑上最早的事务，从而保证完成。在事务之外发起的用户级请求使用时间戳时钟的当前值，实际上变成了一个非常短的事务。内核或 I/O 设备的请求不是事务性的，也不会停止。这是使用保留的时间戳 0 实现的。

使用广播和目录来实现隔离性

事务隔离通过两级方法强制执行 。第一级——所有四个实现都通用——扩展了 L1 和 L2 缓存状态，类似于其他事务性内存系统。每个缓存块的状态包括读取 ® 和写入 (W) 位。TTM 模式下的加载设置块的 R 位。 TTM 模式下的存储检查块的 W 位，如果未设置，则设置它并将块的虚拟地址和以前的数据附加到日志中。缓存闪存清除 R 和 Wbits 以有效地处理事务提交和中止。

第一级支持处理预期的常见情况：事务小到足以放入缓存中。写无效缓存一致性协议确保只要缓存保存块的副本，它就会看到对与事务的读写集冲突的块的所有请求。二级支持处理事务溢出二级缓存（或集合）并且必须替换或写回待处理事务的读取或写入集中的块的情况。系统必须检测（潜在的）冲突，但可以保守地检测，因为我们预计大交易相对不常见。这些实现——广播和目录一致性协议——通过高估溢出任何特定缓存集的事务的读写集来确保在有限的硬件下正确执行。也就是说，它们允许误报，影响性能但不影响正确性。

广播： 对于广播一致性协议 [1, 27]，TTM-Bcast 使用 Bloom 过滤器的变体——类似于部分地址过滤器 [30]——来总结被驱逐块的兰德 W 状态。然而，与传统的布隆过滤器不同，TTM-Bcast 冲突过滤器每个条目只需要两个位，而不是一个计数器（图 1（b））。当 L2 缓存逐出设置了 R 或 W 位的块时，它会在相应的过滤器条目中设置相应的位。传入的一致性请求与 L2 访问并行访问过滤器。过滤器的结果仅在缓存不匹配时才有意义，因为过滤器仅检测与被驱逐块的潜在冲突。这两位编码三种可能的状态 (R, W)：(0, 0) 没有可能的冲突，(1, 0) 至少已读取一个块，但未修改任何块，以及 (1, 1) 至少已修改一个块已被驱逐。在过滤器中发生冲突的外部请求的处理方式与在缓存中发生冲突的条目相同。过滤器中的所有位都在事务开始、提交和中止时使用闪存清除电路清除。

目录： TTM-Bcast 过滤器依赖于查看所有潜在的冲突访问。虽然广播协议确保所有节点都能看到所有一致性请求，但目录充当了自然过滤器以减少带宽。TTM-Dir 扩展了目录协议以确保缓存继续接收冲突访问，即使在逐出设置了 R 或 W 位的块之后也是如此.

幸运的是，大多数目录协议——包括我们的基础协议——已经提供了对 R 位的支持。这是因为它们实现了 S 和 E 相干状态中块的静默（也称为非通知）替换。我们将这些称为“粘性”状态，因为即使缓存状态发生了变化，目录仍停留在先前的状态。例如，如果另一个处理器尝试在“sticky-S”中写入块，则目录将向该处理器发送无效消息。

TTM-Dir 使用“sticky-M”状态扩展目录协议。当缓存写回设置了 W 位的数据时，目录进入 Sticky-M。内存已更新，但sticky-M 状态确保所有请求继续转发给先前的所有者。如果处理器重新访问先前写回粘性 M 的块，则该目录将返回处于状态 M 的块，即使该处理器仅请求共享副本。处理器立即设置 R 和 W 位以检测未来的冲突。

TTM-Dir 可以使用 TTM-Bcast 的冲突过滤器来推断传入的一致性请求何时指示事务冲突。然而，因为目录已经过滤掉了大多数一致性请求，TTM-Dir 使用单个“溢出”位来检测事务适合缓存的（常见）情况。单个位就足够了，而不是单独的 R 和 W 位，因为缓存可以根据请求类型（例如，无效与读取）推断目录状态（以及先前的 R 和 W 位）。溢出位在中止和提交，但sticky-M状态不是（这将需要与每个块的目录进行额外的消息交换）。虽然挥之不去的sticky-M块会导致一些错误的冲突，但它们只发生在少数情况下，即一个长事务的状态一直持续到同一处理器处于另一个长事务中（因为溢出位将过滤掉短事务期间发生的错误冲突）。 TTM-Dir 使用完整目录，尽管有限目录也可以工作（但会产生更多错误冲突）。

交易中止支持

TTM 接口定义了一个在线程执行上下文中运行的软件中止处理程序。这提供了简单的概念模型——用户级执行——即使在出现异常情况（例如，页面错误）的情况下也可以处理复杂的排序。但是，该接口还允许实现使用硬件加速器来提高中止性能。

轻量级： 轻量级 TTM 中止实现立即将控制权转移到软件中止处理程序。处理程序是一个简单的循环，它对日志条目进行排序，调用低级别的undo_log_entry() 调用来恢复之前的图像。 Undo_log_entry() 被实现为一个块存储指令，它在出错时绕过缓存。处理程序恢复所有缓存块的前图像后，通过调用complete_abort_with_restart()完成中止，清除缓存的R和W位，恢复寄存器检查点，并重新启动事务。此调用还清除了 TTM-Bcast 过滤器和 TTM-Dir 溢出位。

Heavy： 重量级中止实现使用与上述相同的机制，但添加了硬件引擎来加速日志回滚。中止加速器是一个简单的状态机，它遍历日志，直接调用低级日志撤消机制。 abort accelerator 减少了常见情况的开销。软件处理程序仅在 abort accelerator 遇到异常情况时调用，例如软件实现的 TLB 未命中或页面错误。

评估

评估本节针对 SPLASH-2 基准套件 [46] 中的几个微基准和并行应用程序评估四个 TTM 实现 - 加上两个使用测试和测试集 (TATAS) 锁的基线系统。第 4.1 节描述了仿真模型，第 4.2 节介绍了微基准和结果，第 4.3 节描述和分析了 SPLASH-2 基准的事务版本。

总结

本文介绍了线程级事务内存 (TTM)，它与虚拟内存一样，抽象出底层的实现细节。 TTM 在两个关键方面与先前的事务性记忆系统不同。首先，TTM 支持多种实现，从所有软件到主要是硬件，允许一系列具有成本效益的替代方案。其次，由于 TTM 在虚拟内存中保留了前映像日志，因此可以缓存旧值和新值。这既减少了成功事务的内存流量，又加速了中止的处理。

我们评估了四种 TTM 实现——基于目录和基于广播的缓存一致性时间用于中止的轻型和重型硬件。微基准测试说明了 TTM 系统简化多线程编程的潜力以及 TTM 优于其他事务性内存实现的潜力。我们证明了 TTM-Light 与 TTM-Heavy 具有竞争力，即使是频繁中止，这表明全硬件解决方案是不必要的。使用 SPLASH-2 基准的四个“事务化”版本，我们证明了与使用传统锁相比，TTM 系统实现了可比或优越的性能