Crafty: Efficient, HTM-Compatible Persistent Transactions

Introduction

NVM拥有非易失性和字节访问的特点，在大数据分析和数据库应用前景广阔（2020的文章）。有效使用NV M的首先挑战就是崩溃一致性的问题，持久性内存的更新是原子性事务，在程序崩溃时，这些更新要么全部 提交，要么不提交，确保重要的数据结构始终处于一致的状态。

先前的关于PM的工作，主要有两个缺点。首先是性能问题，无论是undo logging、redo logging又或 者是Cow，都面临着写性能低下、扩展性差、需要维护shadow memory。其次是和硬件事务内存不兼容， 为了确保正确的恢复，日志条目必须在事务提交之前被持久化，然而事务内存的性质决定了执行中的事务不能执 行持久化操作。

Crafty提出了一种新的非破坏性的undo logging机制，在写持久操作之前利用HTM控制持久化undo log。

motivation

持久事务机制与商用 HTM 不兼容，因为以下困境：为确保正确恢复，日志条目必须在事务提交之前持久化，但HTM的性质决定执行事务不能执行持久化操作。作者指出将value更新与日志更新解耦，即在不修改value的情况下得到日志。

design

整个事务被分为三个阶段： 1.log阶段。该阶段为执行的持久事务生成undo log条目，然后持久化这些条目。这里的关键是不会产生对PM的上数据的任何修改。同时生成一个redo log（位于DRAM）用于第2阶段PM的修改。提交事务后会把undo log下刷到PM中。方法如下伪代码：

2.redo阶段 将redo log中的修改写入到PM当中。但存在的问题，例如线程B的redo阶段可能位于A的log阶段和redo阶段之间，因此需要确保A的redo阶段只有在其前面的log阶段以原子方式执行。为此使用一个全局变量gLastRedoTS表示任何线程最后一次提交成功写入的时间戳。若检测到冲突则进入validate阶段，否则直接更改PM，提交事务。

3.validate阶段 redo阶段所用的原子性检测是充分不必要条件，也就是说有可能多个线程之间没有发生冲突，但redo阶段仍然失败了。此时，validate阶段通过将undo日志中记录的旧值与相同位置的当前值进行比较来检查一致性，validate阶段检查，对于每个程序写入，其在undo日志中的相应条目是否与写入地址和地址处的值匹配。如果是这样，则按照redo log修改PM，提交事务。否则整个事务从log阶段开始重做。

highlights

1.将undo logging的 写日志–>更新对应的值 这个依赖链解耦合。使得undo logging机制应用到HTM当中。 2.validate阶段对于redo阶段的补充，使得性能较没有validate阶段有着一定的提高。 3.使用全局的gLastRedoTS变量记录当前最新提交的事务时间戳，来使多线程并发能够以正确顺序写入以保证log阶段+redo阶段的整体原子性。

drawbacks

1.全局变量gLastRedoTS在HTM中可能导致HTM abort。 2.在竞争激烈情况下，Crafty可扩展性差，随着线程数增加，吞吐量几乎不变，因为crafty通过使用比其他方法更多的HTM机制来实现持久事务，放大了事务冲突。 3.个人认为，crafty在HTM中仍然大量读取PM内容，所以在高并发的情况下，HTM abort的几率太大。感觉HTM适合操作元数据。