匿名节选
并发哈希表：锁粒度与线性化点
Computer Science · 课程论文 · 本科 · 2,200 词
Computer Science课程论文本科
节选在证明什么
本文比较细粒度锁与 lock-free 链表在只读为主负载下的吞吐。关键不在平均延迟，而在扩容时线性化点是否仍然可论证。
学生初稿只有一张平均吞吐柱状图，结论是 lock-free 更快。辅导要求补尾延迟，并单独画出 resize。结果是：扩容时持有全局锁的实现，尾延迟回到粗粒度水平。
报告因此改写比较轴：在稳定状态下的平均，与扩容窗口内的可论证线性化，是两件不同的事。只报告前者，设计分会缺一块。
能把 resize 期间读者是否阻塞画出来，代码评测里的偶发超时才解释得清。节选保留的是这条论证，而不是完整实现。
适合谁
面向本科并发数据结构课：报告如果只贴 throughput 图，通常拿不到设计分。适合写过基准、却说不清线性化点的同学。
覆盖什么
- 细粒度锁与 lock-free 的比较轴不只是平均延迟
- 扩容路径上的线性化点必须可论证
- 尾延迟解释“平均看起来更快”为什么不够
- resize 期间读者是否阻塞要能画出来
- 偶发超时要能指回设计，而不是归咎评测机
怎么进行
- 01先让学生画出插入、查找、扩容三条路径上的锁或 CAS。画不出来，基准数字没有解释力。
- 02在 16 核、只读为主的负载下对比。错误地在 resize 时持有全局锁，会把尾延迟拉回粗粒度实现。
- 03报告把线性化点写进扩容，而不是只写“我们用了 lock-free”。
- 04代码评测里的偶发超时，用这张图解释，而不是再跑一次碰运气。
在 CS / SE / AI 里怎么落地
Computer Science
并发课的设计分在正确性论证。吞吐图是证据之一，不是全文。
Software Engineering
若工程课实现并发组件，同样要把失败负载写进测试计划。
Artificial Intelligence
数据加载流水线的并发 bug 也可以用同一套时序图方法，但模型部分不在此例。
辅导焦点（可迁移的方法）
- 吞吐图必须配失败或扩容窗口
- 线性化点写进文字，不只写算法名字
- 偶发超时要有时序假设
节选经过改写与匿名处理，不是学生提交原文，也不作为代写样本出售。对应学科见课程树。
这一页常被问到的
没有 16 核机器怎么办？
用课程允许的核数，并写清。编造硬件环境帮不了评分，只会让数字不可复现。
lock-free 一定要写吗？
按题目。此例的要点是扩容时的线性化，不是必须上 lock-free。