钟鼓楼

Overview

这本书是对《Science Research Writing For Non-Native Speakers of English》的总结梳理。这本书分为多个章节，每个章节对应一个论文写作里的部分。在每个章节内部，又有如下几个部分：

1. 介绍一下这个章节在整体文章中的作用
2. 展示一篇例文
3. 介绍一些基础的英语语法和词汇
4. 对例文结构进行分析（分解成小组件），也就是他说的 model
5. 对 model 进行一些心法层面的阐述，也就是他说的 key
6. 按照 model 和 key 介绍一些固定词汇、句式和搭配，也就是他说的 vocabulary
7. 最后让你自己写一个文章

很多东西都是实践性质的，并非专业知识本身。所以如果总结的话，其实可以按照 model 的形式来组织 vocabulary ，其他的东西（比如例文、基础语法、动手实践）都可以省略，结构清晰。

因为时间问题，所以我会逐步更新这篇博文。

一、总论

在并行编程中，除了“互斥”这个原语外（一般是采用“锁”来实现），还存在“同步（synchronous）”这个原语，这个原语指的是“各个事件按照特定顺序执行”的需求。比如说在生产者消费者模型中，必须要让生产者先生产，消费者才可以进行消费，这就是一种同步行为，是没有办法仅仅依靠锁来实现的。

当涉及互斥时，涉及到的术语是 lock, unlock, mutex ，而涉及到同步是术语是 wait, signal, notify, barrier 等。之前我只重视了互斥的学习，而对于同步语义，则非常忽视。

二、互斥

本文提出了一种用户态缺页异常处理框架，可以轻松适配不同的处理策略，适用于高并发环境。其亮点在于：

• 框架的易用性：
  • 基于 Linux 的 Semi-Microkernel 设计
  • 透明
• 性能：
  • 采用了微内核和外核思想中的 upcall 设计
  • 采用了先进的异步批处理 IO 后端 io_ring

一、背景

1.1 特化内存管理

从软件层去看，目前内存密集型应用越来越多，如 TB 级的机器学习、大型图计算，内存数据库等。从硬件层去看，硬件新特性有很多，比如分离式内存、分层内存等。这些新的变化都对内存管理策略提出了新的挑战。

通用操作系统的内存管理策略并不适用于内存密集型应用，也不能针对性的利用硬件新特性。有研究表明最大的系统瓶颈是内存管理而不是设备带宽。

一、总论

设计模式是一个工程问题，它不能为某个问题提供具体的答案，它只能让答案写得好看一些。

更进一步地说，设计模式是用于解决代码复杂度高（不是算法复杂度）的问题，这会引发难以阅读，难以维护等伴生问题。当代码量小，复杂度低，没有什么维护需求的时候（比如说科研代码），其实是没有必要采用规范的设计模式的。

我个人学习设计模式，并不是为了写代码（因为我写的代码就是科研代码），而是为了更好的阅读代码，因为大型工程代码都会或多或少遵循设计模式的思路。

很多设计模式解决的复杂度问题，是客观存在的，认识这些问题有助于设计出更加简洁健壮的架构；但是有些问题可能只是类似 Java 等语言表述能力不够所导致的，不用太较真。

一、总论

乱序指的是指令并不按照顺序执行，所以这个概念比较接近软件编程中的“异步”概念（强调对于顺序时序的破坏）。而我之前似乎一直把它和“并行”挂钩（强调对于共享资源的争用）。这种认识倒也不算是错误，目前学了一圈下来，感觉其实和两个概念都有关系。

在顺序模型下，指令是一条条阻塞执行的，必须前一条指令执行完，才能执行后一条指令。那么如果前一条指令非常花时间，那么后一条指令就只能阻塞等待。这个问题是用流水线解决不了的。流水线中的指令也需要顺序执行。而乱序执行就打破了这种顺序执行的阻塞性，使得前序和后序指令可以并行执行。

二、冒险（hazard）

VeriSMo 的可信基只包括硬件和它自己（VM），剔除了对于 Hypervisor 的信任。传统的 VM 的安全服务是由 Hypervisor 负责的，如果认为 Hypervisor 是不可信的，那么就不能由它来提供安全服务。AMD 提供了新的安全架构 SEV-SNP，它为在 VM 中独立实现安全服务提供了支持，VeriSMO 就利用了这个硬件特性。

除了利用新的硬件安全特性外，VeriSMo 在开发时完成了形式化验证来确保安全性。VeriSMo 的开发语言是 Rust，已经确保了部分的内存安全性（也就是 Rust Checker 承担了部分形式化验证的任务），距离完全的形式化验证还有两个挑战：

1. 因为 Hypervisor 不可信任，所以 Hypervisor 可以打断 VM 的执行并修改硬件状态，这种并行无法简单验证。
2. 开发 VeriSMo 需要使用 Unsafe Rust，Rust Checker 无法验证这种情况。

为了解决挑战 1，VeriSMo 将验证拆分成了 2 层，上层为机器模型层（Machine Model），用 model verify 专门约束 Hypervisor 的行为，下层为实现层（Implement），用于解决排除了 Hypervisor 干扰后的 VeriSMo 本身的验证问题。