准备
proxy lab 的难度和 malloc lab 不在一个数量级上,主要体现在两个方面:
- 除了第三部分要实现 cache 以外,前面两部分要求实现 proxy 和 synchronization, 都可以在书上的示例代码中拼凑出来;
- 测试评分宽松,通过就满分,malloc lab 可是按性能评分的;
简单归简单,但是不能不做准备工作:
- 仔细看一遍 proxy lab 的说明文档,在 csapp3e labs 官网上;
- 熟读 csapp3e 第11章,略读第10章,第12章;
要求实现三个功能:
代码
proxy
这部分的代码大半都可以复用 tiny.c 的代码,包括函数 read_requesthdrs
,
clienterror
, doit
的大部分, main
的大部分。
定义几个字符串全局变量做为请求的头部分:
|
|
别忘了 lab 说明文档中要求在 proxy 的运行过程中遇到 sigpipe
信号时不要报错:
|
|
以及负责解析 client 发送的网址请求(原谅我,就像注释中说的,这个函数我没有自己写, 只是稍微改了一下,被 malloc lab 折腾惨了,抠细节的代码不想再写了):
|
|
main
函数的前半部分和 tiny.c 的一致,在检查命令行参数是否合法之后:
|
|
然后就是 do_it
函数,它负责 proxy 的主要功能:
|
|
这样就可以实现一个简单的单线程 proxy 功能。
synchronization
大部份相关代码都可以借鉴 CSAPP3e 第12章的关于并发编程的例子(Pthread):
一个 thread 包装函数:
|
|
在 main
函数中修改原来调用 do_it
的那部分代码:
|
|
如果前面 proxy 功能能通过测试的话,这个多线程就可以正常工作。
cache
这里实现的是一个双向链表来存储缓存内容(感谢 malloc lab 给的灵感),就像前面所说 的,proxy lab 测试要求比较低,并没有很复杂的边界条件,通过测试是没有问题的,但是 这个双向链表实现出来以后有些地方不能和说明文档里的要求(可能只时建议)保持一致:
由于缓存替换要求实现 LRU 算法(或者接近 LRU),作者在这里是严格按照 LRU 算法 来做的,具体是:
- 每次读写都算做一次使用该链表元素
- 讲新近读写的缓存从链表中挑出,将它的前后链表关系置为
NULL
- 链接它的前后元素
- 插入链表头
但是问题就来了,因为这是一个支持多线程的 proxy, 这些线程共用一个链表(当然了), 所以每次更新链表的操作就需要加 锁, 每次读写都需要;虽然我在读缓存的代码中加 入了一个条件判断语句:如果链表头就是当前缓存元素,就跳过链表更新;毕竟如果有 多个线程同时读一个缓存的话,第一个加锁并读完的的线程将会把它置于链接头并释放 锁,后面等待的线程就可以跳过更新链表操作从而实现说明文档上的读并行;但是如果 有特别复杂的线程并行情况,比如最坏的情况:大量并行线程读取两个不同的缓存,链 表头更迭频繁,读并行就无法实现了。
大量的链表链接关系更新,多线程导致每处链表关系更新和读取都需要加锁;也考虑过 用单向链表和缓存内加时间戳来实现 LRU 算法,但是,单向链表的添加和解除元素在多 线程的情况下还是得加锁,并没有很大得并发提升。
写缓存在说明文档中是明确要求加锁(或者生产者消费者并发模形),在缓存结构体中 添加一个
mutex
来实现,每次要写缓存都要添加锁和释放锁。使用固定大小的数组来取代链表?在多线程情况下从数组中存取元素照样得上锁;
综上这些问题都是选用链表而引出来,单向或者双向都无法避免,应该还会有对并发更 友好数据模形,实在不想折腾了(在经过 malloc lab 得折腾之后作者已经懈怠了), 等以后知识量上去了,或者真的有灵光一闪,再来处理这个。
#: 看了下 CSAPP3e 12.5.14 P707 读者优先的读者-写者模形, 一部分实现读者优先的代码可以借用到 cache.c 的读缓存函数里,可以实现读缓存的并 行实现(不过极端条件下当并行读取的进程同时进入
if(!(cache_node =
CACHE_HEAD))== 时,就几乎没有并行可言了);书中的读者-写者模形整体来看并不适合 做 proxylab 要求的缓存:书中的模形过于简单,基于生产者-消费者模形的-有东西 产出就取走,而缓存要求的是有匹配的内容就读取该内容,无匹配就将获得的数据做为 缓存插入,不过sbuf
这个数据结构还是可以借用的,需要大改,改造思路就是 LRU 链表替换原来的数组,或者保理数组,新加入一个数据结构存储每一个缓存的地址并桉 照 LRU 顺序排列;
缓存结构体:
|
|
配套方法:
|
|
在 proxy.c 中实现缓存,在 main
函数中初始化链表:
|
|
检查 client 提交的 uri 有没有缓存,如果没有缓存,按原来的逻辑执行下去并缓存收到的内容:
|
|
写在后面
proxy lab 这样结束掉虽然能通过测试,它现在内部的代码逻辑还是存在很多问题的;
这次作者选择划水;
一来这次的 lab 过于功能性,网络编程和并发编程的知识结构比较顶层,做了收获有限, 投入大量时间并不值得;
二来作者当前的知识量也不够(数据结构、算法、一些顶层实现的函数接口),深挖下去效 率太低,这些时间可以花在更重要的事情上。
就这样吧,这里的代码以后会有重构的那一天的。
7 稍微改进了读缓存的并行性 。