6.824 2020春 材料阅读 6.033 chapter9

0. 序

本节内容对应lecture12, 感觉核心是讨论distributed transaction.

1. two phase lock

• 一种加锁的基本方法，针对9.5.2中的simple locking的优化，保证concurrent transaction is serializable，遵循两个原则：
  • 在读或写任何object前都先加锁
  • 直到完成所有object的读写后才能释放锁（一个小优化：在获取所有锁之后，且在完成所有object读写前，如果某个object是只读的，并且以后再也不需要读了（包括 crash recovery），就可以释放掉该锁）
• 上面的小优化有两点很重要，首先是要获取到所有锁之后，才能把某个只读数据的锁给释放掉。举一个例子，比如如下两个transaction.

init: x=10,y=8
T1:
read x
write y = x+1
T2:
read y
write x = y + 1

# serializable results
# T1->T2: x = 12, y = 11
# T2->T1: x = 9, y = 10

如果T1获取到x锁，读x后便释放掉x锁，此时T2同时获取到x,y锁并执行完毕，随后T1获取到y锁，然后T2执行完毕，最终得到的结果是x=9, y=11，并不是一个串行化的结果。

• 另外值得考虑的一点是为什么要求只能释放只读数据的锁，而不能释放已经修改数据的锁。我想可能的原因是考虑到transaction abort，这时需要复原已经修改的数据，违背了释放锁后不再读写该数据的原则。
• 另外值得考虑的一点是材料中提到的如果从transaction的描述中不能直接知道需要获取哪些锁，而需要读一些object，然后才知道到底需要哪些锁。
• 在simple locking中，需要提前获取所有可能读或写的锁，然后再进行查找，找出自己实际需要修改的object，再进行修改，最后释放所有的锁
• 一个最典型的例子是文件系统，修改一个文件的数据前需要获取该文件对应的锁，但为了知道该文件对应的inode锁的位置，需要沿着目录查找，每次读目录时需要获取该目录对应的锁，读取目录，然后查找下一级，释放掉上一级目录的锁…最终找到该文件对应的inode，获取该inode的锁，然后对文件进行修改。
• 直觉上来看，上面描述的文件系统的加锁方式实际上违背了two phase lock的原则，虽然最终只需要object文件的锁，但是释放掉中间查找的目录锁也应该在获取到object文件锁之后，否则对文件系统的操作可能不是serializable的。
• 我对上面的矛盾的解释是，对文件系统的操作本身并不支持完整的transaction属性，或者说，从文件系统的设计者的角度和应用的角度考虑，牺牲完整的transaction属性来获取更多的并行性是值得的。
• 以文章riscv-xv6单步调试x 文件系统2中分析的xv6文件系统为例，xv6操作系统支持的有关文件系统的系统调用有write, unlink，如果write写的字节数不多（被xv6文件系统的log区大小限制），那么xv6操作系统的write是原子操作，即用write写100个字节，不会被观测到写50个字节的文件系统状态。同样，unlink也是一个原子操作。那么unlink和write之间如何做到serializable呢？
• 我们考虑这样一种情况，write操作写文件/tmp/abc，同时unlink操作删除文件/tmp/abc，unlink操作需要做两件事，删除/tmp目录中对应的表项，同时释放文件abc占用的inode以及block资源。假设write在获取/tmp目录锁后，读取/tmp目录内容后找到了文件abc对应的inode，然后释放掉/tmp锁，尝试获取文件abc对应的锁。此时unlink同时获取了/tmp目录锁和文件abc锁，随后删除了文件abc。这时write函数的执行岂不是就发生错误了？
• xv6文件系统避免这个问题的方法是采用引用计数，在write函数拿到inode对应指针后，就增加inode的引用计数（即使此时没有拿到inode锁），因此在unlink执行完毕后，并不会删除掉inode，而是把该inode的真正删除留到write执行完毕之后。最后看起来串行化的结果就是write->unlink
• 也就是说，为了获得原子操作的性质，如果不遵循two phase lock的加锁规则，需要付出一些额外的代价。另一方面，额外的引用计数也并没有使得文件系统具有完整的transaction属性，至少，数据库的transaction可以由用户自行定义，而文件系统提供仅向用户提供了有限的transaction。例如，xv6的文件系统无法提供这样一条原子性的系统调用：在修改文件名的同时修改文件的内容。
• 这貌似也能解释Frangipani笔记中的遗留问题，Frangipani文件系统采用了two phase lock的一种变体，在搜寻目录时也会释放掉该目录锁，不过一旦检测到该目录内容被修改，就需要释放掉所有已经获得的锁，对目录进行重新搜寻。

2. two phase commit

TODO…（懒癌又犯了）