6.824 Lab4: Cache Locks回顾

在该项目中，server扮演的是分布式文件系统的角色，为了保证consistency，所有client对文件的访问及修改需要首先申请对应资源的锁－－每个资源，无论是文件还是目录，都有它自己的id和锁。

锁的分配与释放，可以是基于严格一致性（任何时候，用户修改了某个资源，则该资源的最新值是所有用户都可见的）的：用户申请资源时，从lock server获取锁；资源使用完毕后，将锁释放，返回给lock server。但是这样可能会带来很多不必要的网络开销：设想一个client有若干个独立线程，每个线程都想访问资源A，在严格一致性的要求下，每个线程需要单独的向lock server去申请使用锁，然后释放给lock server。有N个线程，就意味着有2N次网络请求。

其实可以将一致性的要求稍稍放宽，当client申请到锁以后，可以把锁看作是进程资源，而非线程资源。当某一个线程释放锁时，并不是把锁直接返还给lock server，相反，锁仍然留在本地，仅仅把它的状态置为FREE。这样，如果有其他线程需要访问该锁时，并不会产生网络开销，因为锁是在本地的。随之而来的复杂性就是，如果锁成了本地锁，其他client如何获取这个资源？

YFS的解决方案是：建立一条从lock-server到client的tcp连接，在该连接中，client作为server端。这样，lock-server就拥有了可以通知client归还锁的机会。假设client1拥有锁lock-hot，当client2向lock-server请求此锁时，
在lock-server端：
if 有其他client也在等待该锁，then
将client2置入该锁的等待队列尾；
else lock-server向client1发出一个revoke请求，要求其归还锁
if client1能够立刻归还锁（当下并没有使用），then
if 在发送“漫长的网络请求”revoke请求中，有其他client来申请该锁并被加入等待队列中，then
先给client2发送一个revoke请求，告诉它有其他用户希望得到该锁，一旦使用完毕，请尽快归还。
else none
将锁授予client2；
else 将client2放入锁lock-hot的等待排队列表中，等待client1归还该锁。
ps, 请注意，这里并没有给出lock-hot初始就是FREE的情况。


在client1端：
client1首先查看该锁在本地的使用情况，
if 没有任何线程在使用它，then
if 没有排队等待线程（当某一个线程使用lockhot完毕并将其置为FREE时，刚刚到达的revoke请求可能会先于其他已经在等待lock-hot的本地线程先获得对该锁的访问权）, then
直接归还锁给server；
else 并不直接归还锁，而是设置一个标记量，一旦该锁被释放（注意，锁在本地，则本地线程拥有获取该锁的优先权，以避免再次申请的网路开销），client1会主动释放锁给server。
else 设置一个标记量，一旦该锁被释放client1会主动释放锁给server。