在并行编程中，除了 “互斥” 这个原语外（一般是采用 “锁” 来实现），也就是不同的任务不能同时做一件事情。还存在 “依赖（dependency）” 这个原语，这个原语描述的是有些任务必须在另外的一些任务后面开始，也就是虽然任务基本上都可以并行异步的执行，但是有些时候存在一些依赖使得任务需要按照一定的次序来执行。
依赖可以被抽象成一种图结构，其中节点是任务，而边是任务之间的依赖关系。但是图结构其实并不好在编程中使用，所以我们又用 event ，信号量等抽象简化了这种图结构。我理解其实是用生产者消费者模型来改写了图结构，构成了一种 “以依赖关系为中心” 的编程模型。
Barrier 或说者同步，我觉得其实也是一种依赖关系，它指的是同一个 batch 中的任务，必须依赖于其他 batch 任务的结束才能结束。
当涉及互斥时，涉及到的术语是 lock, unlock, mutex ，而涉及到依赖是术语是 event, wait, signal, notify, barrier 等。之前我只重视了互斥的学习，而对于同步语义，则非常忽视。
本文提出了一种用户态缺页异常处理框架，可以轻松适配不同的处理策略，适用于高并发环境。其亮点在于：
- 框架的易用性：
- 基于 Linux 的 Semi-Microkernel 设计
- 透明
- 性能：
- 采用了微内核和外核思想中的 upcall 设计
- 采用了先进的异步批处理 IO 后端 io_ring
从软件层去看，目前内存密集型应用越来越多，如 TB 级的机器学习、大型图计算，内存数据库等。从硬件层去看，硬件新特性有很多，比如分离式内存、分层内存等。这些新的变化都对内存管理策略提出了新的挑战。
通用操作系统的内存管理策略并不适用于内存密集型应用，也不能针对性的利用硬件新特性。有研究表明最大的系统瓶颈是内存管理而不是设备带宽。
设计模式是一个工程问题，它不能为某个问题提供具体的答案，它只能让答案写得好看一些。
更进一步地说，设计模式是用于解决代码复杂度高（不是算法复杂度）的问题，这会引发难以阅读，难以维护等伴生问题。当代码量小，复杂度低，没有什么维护需求的时候（比如说科研代码），其实是没有必要采用规范的设计模式的。
我个人学习设计模式，并不是为了写代码（因为我写的代码就是科研代码），而是为了更好的阅读代码，因为大型工程代码都会或多或少遵循设计模式的思路。
很多设计模式解决的复杂度问题，是客观存在的，认识这些问题有助于设计出更加简洁健壮的架构；但是有些问题可能只是类似 Java 等语言表述能力不够所导致的，不用太较真。
乱序指的是指令并不按照顺序执行，所以这个概念比较接近软件编程中的 “异步” 概念（强调对于顺序时序的破坏）。而我之前似乎一直把它和 “并行” 挂钩（强调对于共享资源的争用）。这种认识倒也不算是错误，目前学了一圈下来，感觉其实和两个概念都有关系。
在顺序模型下，指令是一条条阻塞执行的，必须前一条指令执行完，才能执行后一条指令。那么如果前一条指令非常花时间，那么后一条指令就只能阻塞等待。这个问题是用流水线解决不了的。流水线中的指令也需要顺序执行。而乱序执行就打破了这种顺序执行的阻塞性，使得前序和后序指令可以并行执行。
VeriSMo 的可信基只包括硬件和它自己（VM），剔除了对于 Hypervisor 的信任。传统的 VM 的安全服务是由 Hypervisor 负责的，如果认为 Hypervisor 是不可信的，那么就不能由它来提供安全服务。AMD 提供了新的安全架构 SEV - SNP，它为在 VM 中独立实现安全服务提供了支持，VeriSMO 就利用了这个硬件特性。
除了利用新的硬件安全特性外，VeriSMo 在开发时完成了形式化验证来确保安全性。VeriSMo 的开发语言是 Rust，已经确保了部分的内存安全性（也就是 Rust Checker 承担了部分形式化验证的任务），距离完全的形式化验证还有两个挑战：
为了解决挑战 1，VeriSMo 将验证拆分成了 2 层，上层为机器模型层（Machine Model），用 model verify 专门约束 Hypervisor 的行为，下层为实现层（Implement），用于解决排除了 Hypervisor 干扰后的 VeriSMo 本身的验证问题。
系统安全有 3 个目标：
合称 CIA 。