MIT-6.S081-2020实验（xv6-riscv64）八：lock

实验文档

概述

这次实验主要涉及锁在内核的应用，没有用到什么特别的理论知识，但是编程的时候陷阱重重，要么资源竞争，要么死锁，和实验三差不多，非常考验耐心和细心。

内容

Memory allocator

这个任务要求给物理内存分配程序重新设计锁，使得等待锁时的阻塞尽量少。可以按CPU的数量将空闲内存分组，分配内存的时候优先从当前所用CPU所管理的空闲内存中分配，如果没有则从其他CPU的空闲内存中获取，这样就可以把原来的锁拆开，每个CPU各自处理自己的空闲内存时只要锁上自己的锁就行了：

void
kinit()
{
  for (int i = 0; i < NCPU; i++) initlock(&kmem[i].lock, "kmem");
  freerange(end, (void*)PHYSTOP);
}

void
kfree(void *pa)
{
  struct run *r;

  if(((uint64)pa % PGSIZE) != 0 || (char*)pa < end || (uint64)pa >= PHYSTOP)
    panic("kfree");

  // Fill with junk to catch dangling refs.
  memset(pa, 1, PGSIZE);

  r = (struct run*)pa;

  int cpu_id; push_off(); cpu_id = cpuid(); pop_off();
  acquire(&kmem[cpu_id].lock);
  r->next = kmem[cpu_id].freelist;
  kmem[cpu_id].freelist = r;
  release(&kmem[cpu_id].lock);
}

由于kinit这个函数不是并行的，所以一开始会将所有空闲内存都交给一个CPU管理。

void *
kalloc(void)
{
  struct run *r;

  int cpu_id; push_off(); cpu_id = cpuid(); pop_off();
  acquire(&kmem[cpu_id].lock);
  r = kmem[cpu_id].freelist;
  if(r) {
      kmem[cpu_id].freelist = r->next;
      release(&kmem[cpu_id].lock);
  } else {
      release(&kmem[cpu_id].lock);
      for (int i = 0; i < NCPU; i++) if (i != cpu_id) {
          acquire(&kmem[i].lock);
          r = kmem[i].freelist;
          if (r) {
              kmem[i].freelist = r->next;
              release(&kmem[i].lock);
              break;
          } else release(&kmem[i].lock);
      }
  }
  ......

Buffer cache

这个任务要求给硬盘缓存分配程序重新设计锁，使得等待锁时的阻塞尽量少。但是，因为硬盘缓存包含遍历查找操作，即查找当前硬盘块是否已被缓存，显然这时就不能把缓存也按CPU进行分配，加上这个任务的操作也比较复杂，因此比上个任务多了很多问题。

实验文档给出的分配方式是对硬盘块号进行取模哈希，数据结构如下：

struct {
  struct spinlock lock;
  struct spinlock block[BNUM];
  struct buf buf[NBUF];

  // Linked list of all buffers, through prev/next.
  // Sorted by how recently the buffer was used.
  // head.next is most recent, head.prev is least.
  struct buf head[BNUM];
} bcache;

这里保留了原来的锁是因为在不要求修改的bpin、bunpin函数中使用了，但要小心的是，既然用到了新定义的锁，那么在整个实验中所有相关的代码都必须用新定义的锁，不能用原来的锁。

void
binit(void)                                                                     {
  struct buf *b;

  initlock(&bcache.lock, "bcache");

  // Create linked list of buffers
  for (int i = 0; i < BNUM; i++) {
      initlock(bcache.block + i, "bcache");
      bcache.head[i].prev = &bcache.head[i];
      bcache.head[i].next = &bcache.head[i];
  }
  for(b = bcache.buf; b < bcache.buf+NBUF; b++){
    b->next = bcache.head[0].next;
    b->prev = &bcache.head[0];
    initsleeplock(&b->lock, "buffer");
    bcache.head[0].next->prev = b;
    bcache.head[0].next = b;
  }
}

因为一开始所有的缓存对应硬盘块号都是0，所以把它们都放到0号桶里。

void
brelse(struct buf *b)
{
  if(!holdingsleep(&b->lock))
    panic("brelse");

  releasesleep(&b->lock);

  int entry = b->blockno % BNUM;
  acquire(bcache.block + entry);
  b->refcnt--;
  if (b->refcnt == 0) b->ticks = ticks;
  release(bcache.block + entry);
}

释放缓存时只要获取块对应的桶对应的锁即可，由于原来的代码在释放缓存时会将缓存插在head的下一个节点，按照原来程序的思路head的下一个节点是目前最近使用的缓存，所以把查找最久未使用缓存的方式改成了查找最前时间戳后，这里也应该更新时间戳。

最麻烦的是bget，这里拆成两部分，第一部分是待查找磁盘块已被缓存的情况：

  int entry = blockno % BNUM;
  acquire(bcache.block + entry);

  // Is the block already cached?
  for(b = bcache.head[entry].next; b != &bcache.head[entry]; b = b->next){
    if(b->dev == dev && b->blockno == blockno){
      b->refcnt++;
      release(bcache.block + entry);
      acquiresleep(&b->lock);
      return b;
    }
  }

也是只要获取待查找块对应的桶对应的锁即可，但要注意一个问题，这个锁必须一直持有到整个函数运行结束，不能在中间释放了再重新获取，也就是说：

获得锁
查找缓存但没找到
释放锁
可以并行的其他操作
获得锁
更新一个可用的缓存
释放锁

不等价于

获得锁
查找缓存但没找到
可以并行的其他操作
更新一个可用的缓存
释放锁

而且前者是错的，后者是错的。理由是如果中间释放了锁，当前进程可能会让出控制权执行别的进程，那么就会出现一个问题，比如A进程查找1号缓存，查不到，释放了锁，程序转到B进程，它也查找1号缓存，查不到，释放了锁而刚好B立刻又获得了锁，继续往下更新了一个可用的缓存，释放锁，这是A获得锁，继续往下更新了一个可用的缓存，释放锁。现在缓存中就有两个编号完全相同且引用数都为1的缓存了，这个是不允许的行为，可能会出现各种问题，而且这些问题的发生全靠运气，有时不出错，有时这个panic，有时那个panic，非常难调。

第二部分是待查找磁盘块未被缓存的情况：

  for (int i = (entry + 1) % BNUM; i != entry; i = (i + 1) % BNUM) {
      uint minticks = 0x3fffffff; struct buf *minbuf = 0;
      acquire(bcache.block + i);
      for(b = bcache.head[i].prev; b != &bcache.head[i]; b = b->prev)
          if (b->refcnt == 0 && b->ticks < minticks) {
              minticks = b->ticks; minbuf = b;
          }
      if (minbuf != 0) {
          minbuf->dev = dev;
          minbuf->blockno = blockno;
          minbuf->valid = 0;
          minbuf->refcnt = 1;
          minbuf->next->prev = minbuf->prev;
          minbuf->prev->next = minbuf->next;
          minbuf->next = bcache.head[entry].next;
          minbuf->prev = &bcache.head[entry];
          bcache.head[entry].next->prev = minbuf;
          bcache.head[entry].next = minbuf;
          release(bcache.block + i);
          release(bcache.block + entry);
          acquiresleep(&minbuf->lock);
          return minbuf;
      }
       release(bcache.block + i);
  }
  panic("bget: no buffers");
}

一开始我寻找可更新缓存的办法是直接遍历整个数组，为了防止竞争，需要在遍历前把所有的桶锁起来，然而这样会发生死锁，即假设处理0号桶的进程运行到这里，把0号桶锁了，准备获取1号桶的锁，与此同时处理1号桶的进程运行到这里，把1号桶锁了，准备获取0号桶的锁，这样就死锁了。仔细分析原因，发现只要锁桶的顺序是乱序的，都可能发生死锁，这里的解决方法是使用“资源有序分配法”，就如上面的循环，从当前桶的下一个桶往上遍历到当前桶的前一个桶（循环遍历），保证了顺序，就不会死锁了。另外一个需要小心的是链表的操作，双向链表确实很容易写错，需要谨慎。

---

总结一下，这个实验和上一个实验相比，感觉更考验并行思维，主要体现在锁的应用，上个实验的后两个任务和这个实验比真的是小巫见大巫了，可能设计实验的老师主要还是想让学生熟悉一下pthread才弄那两个任务，毕竟pthread太常用了。目前觉得系统编程最难的就是四个问题：缺页错误（这里指的是编程逻辑的错误导致的错误）、内存泄漏、资源竞争、死锁，都是极为难以检查难以调试的。