在初赛阶段告一段落后，由于考试等个人原因，开发进度暂停。
决赛名单出后，深感幸运。当时我感觉，剩下的任务不太多了，应该有时间进行一些创新，同时可以弥补一下初赛阶段遗留下来的问题。但后来证明，我对局势的判断不完全正确。
7 月 9 日，队内进行了线下交流，队员对题目二等较复杂的代码进行了简单介绍，同时对 Git、Markdown 的使用进行了探讨，队内还讨论了变量命名、缩进和空格等代码规范相关的软件工程问题。最后，大家就未来一段时间中的个人时间等情况作了说明。这时，我才发现时间比较紧张。
7 月 11 日，我们与马玉昆老师进行了交流。针对初赛中尚未完成的第三题，马老师表示此功能先搁置，待其他功能完成后才可以进行。
针对抓取进程持有锁信息的问题，马老师认为，此功能可以通过 KProbe 对相关的函数加以追踪，他表示由于内核中所有的锁的上锁均可追溯到同一个函数，只需调整相关的编译选项即可。（如果直接用 lockdep 等的话，可能对性能影响太大）抓到相关信息后，再分析关中断的进程持有锁的情况，并采用更加可视化的方式输出。
会后，针对初赛中完成不够完善的开机自启问题，叶景熙同学将进一步加以完善。赵子晗同学希望阅读一些相关的材料。
操作系统钟竞辉老师鼓励我们，只要坚持到底就有希望。
我在网络上查找到 INTspect 这一工具，其似乎将数据的分析拿到用户态进行，这种设计给了我启发。这样或许有利于提高安全性。
针对技术文档写作规范问题，无意间看见一份 Markdown 写作规范，中间提到不少内容。
由于乱序执行的存在，后面的指令可能会先于前面的指令执行完毕；编译器在编译时，出于优化的考虑，可能会将部分指令重排。为了保证指令的顺序执行，可以使用内存屏障。
现有代码在实现“锁”时并没有考虑到这一层（主要是我那时还不了解这方面的知识），我担心存在多核心并发时此前版本用原子量实现的“锁”并不能如期工作，后来看了几篇关于 Linux 自旋锁设计从简单的原子量到 Ticket Spinlock 再到 MCS Lock 等的演进，再加上了解到有 spin_lock_irqsave 和 spin_unlock_irqrestore 这两个可以保存中断状态的函数，还是觉得用自旋锁更好一些，自己的锁还比较初级。
摘自《Linux 内核设计与实现》第 3 版：
每个处理器在任何指定时间点上的活动必然概括为下列三者之一：
- 运行于用户空间，执行用户进程；
- 运行于内核空间，处于进程上下文，代表某个特定的进程执行；
- 运行于内核空间，处于中断上下文，与任何进程无关，处理某个特定的中断。
以上所列几乎包括所有情况，即使边边角角的情况也不例外，例如，当 CPU 空闲时，内核就运行一个空进程，处于进程上下文，但运行于内核空间。