基于 ebpf-rca 项目代码，从 OS 基础知识出发，逐层理解 eBPF。

1. eBPF 是什么

eBPF = 内核内虚拟机，完整构成四件套：

不是"轻量 hook"，而是"一段能跑在内核里的受限 C 代码"。

核心模型：用户态编译 eBPF 字节码 → bpf() syscall 注入 → verifier 检查通过 → 挂到内核预定义锚点（tracepoint 等） → 事件触发时执行 → 通过 map 向用户态回传聚合数据。

2. eBPF 是事件驱动的回调（不是持续运行的后台进程）

类比：信号 handler 注册模型。

sigaction(SIGALRM, handler)    ↔  link.Tracepoint("sched", "sched_switch", handler)
  时钟中断触发 → handler 执行     ↔  sched_switch 发生 → eBPF handler 执行
  handler return → 回到被中断代码  ↔  eBPF return → 回到调度器

区别：

• 信号 handler 跑用户态，eBPF 跑内核态
• 信号 handler 只能调 async-signal-safe 函数；eBPF 只能调白名单 helper + 受 verifier 约束（本质都是"中断上下文约束"）
• 信号 handler 仅影响本进程；eBPF 一挂就是系统全局

无事件 = 零 CPU 占用。没有"后台轮询"。

3. eBPF 如何避免 kernel panic — Verifier

Verifier 在加载时（不是编译时）逐指令静态模拟执行，检查：

1. 无死循环 — 循环必须 #pragma unroll（编译期展开），跳转只能向前
2. 无越界访问 — 每次内存访问，必须证明指针合法（判空检查、map value 范围内）
3. 无未初始化变量 — 所有寄存器在使用前有确定值
4. 无除零 — 值域追踪，除数可能为 0 的路径直接拒绝

检查不通过 → 程序拒绝加载，根本不会执行。

Verifier 保证的是"内存安全"，不是"逻辑正确"。 逻辑错误（算错指标、指错进程）不会导致 kernel panic，只会输出错误的诊断结果。

eBPF 能做的：读写 map、算术运算、调白名单 helper。 eBPF 不能做：malloc/free、调任意内核函数、无界循环、直接访问任意内核内存（必须走 bpf_probe_read_kernel）。

4. eBPF 执行模型：跑在触发者的上下文里

不是独立内核线程，是串行插入在触发事件的执行路径中。

CPU0 A 进程时间片到了                   CPU1 正在处理 write() syscall
  │                                      │
  ├── sched_switch tracepoint 触发        ├── block_rq_issue tracepoint 触发
  │     → handle_switch() 同步执行         │     → handle_issue() 同步执行
  │     → return                          │     → return
  │     → 调度器继续                       │     → write() 继续

• 同步调用，不是异步中断或信号投递。tracepoint 是内核源码中硬编码的函数调用点
• run-to-completion：不允许休眠、无 mutex_lock
• 多核之间才真正并发，靠 __sync_fetch_and_add 做原子 map 更新

5. tracepoint：内核自带的"监控探头"

内核开发者在关键位置埋的标记点，平时零开销（不存在），激活后才执行回调。

// 内核源码（kernel/sched/core.c），不是 eBPF
void __schedule(void) {
    // ...
    trace_sched_switch(prev, next);   // ← tracepoint 埋点
}

不是 eBPF 特有的。内核本来就埋了几百个这样的点。eBPF 只是提供了一种向这些点注册回调函数的机制。

6. BPF map：内核与用户态的通信信道

不是 mmap 共享内存。 内核单向拥有内存，两边访问方式不对称：

核心设计：快的那边（eBPF，每秒触发几万次）用直接指针；慢的那边（用户态，每秒只读一次）走 syscall。各取所需。

ebpf-rca CPU 场景的三个 map（cpu.bpf.c:27-48）：

oncpu_start   // tid → 上 CPU 的时间戳         (HASH, 16384 entries)
wakeup_ts     // tid → 被唤醒入队的时间戳      (HASH, 16384 entries)
stats         // tid → {run_ns, runq_ns, ctx}  (HASH, 16384 entries)

7. CPU 开销的真实情况

eBPF 的 CPU 开销 = 单次代价 × 触发频率。

• 正常：无事件 = 无指令执行 = 零 CPU
• 触发：每次 handle_switch 约几十到一百周期（几次哈希查找 + 整数加法），上下文切换本身几千周期
• 开销可控：因为没有 per-event 上送到用户态（没有 copy_to_user）
• syscall 场景（raw_syscalls）是开销最高的：每次 syscall 触发两次 eBPF，一秒几万次

8. eBPF vs Timer 采样：拍照 vs 录像

ebpf-rca 的内存场景刻意混合使用：

• eBPF 抓直接回收事件（偶发但致命，timer 拍不到）
• /proc/meminfo 读可用内存（低频变化，不值得写 eBPF）

选择原则：

• 事件稀疏 + 需要完整性 → eBPF 挂载
• 事件高频 → eBPF 内核态聚合，不上送每条事件
• 本身就是常量 → 直接读 /proc，不用 eBPF

9. ebpf-rca 完整调用链（CPU 场景）

阶段一：加载（一次性）

Go: NewCPUCollector()
  └─ bpf() syscall → 内核 verifier 静态检查字节码
  └─ 创建 3 个 map（oncpu_start, wakeup_ts, stats）
  └─ link.Tracepoint("sched", "sched_switch", handleSwitch)
  └─ link.Tracepoint("sched", "sched_wakeup", handleWakeup)

阶段二：内核事件触发（持续，每切换一次触发一次）

sched_switch 发生
  └─ handle_switch:
       prev 切出: run_ns 累加, ctx++（记录进程名）
       next 上 CPU: runq_ns 累加（结算排队时间）
       → 只做 O(1) 聚合，不判断，不发消息

阶段三：用户态采样（每秒）

Go: time.Ticker 触发
  └─ Poll(1s): 遍历 stats map → 差分 → 算 cpu_util / ctx_per_min / runq_wait
  └─ Detect: 阈值(0.9) + 连续窗口(3)判定异常
  └─ BuildCPUReport: 规则分类根因 + 组装证据链
  └─ output: JSON/YAML/Markdown

阶段四：卸载

Ctrl-C → defer col.Close()
  └─ link.Close() → 从 tracepoint 摘除
  └─ objs.Close() → 释放 map 和程序 fd

10. Map 共享、原子性与统计偏差边界

Map 共享不是缺陷，是内核态聚合的自然选择。 eBPF 程序在事件路径里执行，必须用一个所有 CPU 都能访问的 map 把同一对象的统计累加起来，否则用户态每个窗口要枚举每 CPU 副本再手动归并。

当前 ebpf-rca 使用的是普通 BPF_MAP_TYPE_HASH，不是 per-CPU map：

但要精确地区分两件事：

1. 共享 map 负责聚合位置：所有 CPU 都把同一对象写到同一个 value。
2. 原子操作负责并发写正确性：只有使用 __sync_fetch_and_add 的字段才有原子加保障。

项目里的原子性现状：

所以更准确的判断是：当前设计接受小概率统计偏差，尤其是 max_* 这类 gauge 可能被并发覆盖；I/O/syscall 的主要累计字段用原子加兜底，CPU/lock/mem 更多依赖事件语义降低冲突概率。

真正的 per-CPU map 是 BPF_MAP_TYPE_PERCPU_HASH：每个 CPU 有独立 value，写入时通常不需要跨 CPU 原子竞争。但它不会让用户态“自动得到合并后的一个 value”。用户态读取时通常拿到每 CPU value 数组，再自己求和、取最大值或做直方图合并。代价是读路径和合并逻辑更复杂，收益是高频写路径更低竞争。

本项目选择普通共享 hash map 的工程含义：

• 代码简单，用户态 Poll() 直接读一个 value。
• 适合比赛原型和低到中等负载诊断。
• 对 count/total 类累计值，热点场景最好使用原子加或 per-CPU map。
• 对 max 类字段，即使用原子加也不够，需要 CAS 循环或接受 best-effort。

11. 五个异常场景解析（从 CSAPP 级 OS 知识出发）

前提：你已经理解上下文切换、缺页、read()/write() 系统调用、mutex_lock 阻塞等待。下面每个场景只补一个关键内核事实。

11.1 CPU 异常占用 / 调度延迟

内核侧模型：

sched_wakeup:
  wakeup_ts[tid] = now

sched_switch:
  prev 被切出:
    run_ns += now - oncpu_start[prev]
    ctx++
  next 上 CPU:
    oncpu_start[next] = now
    runq_ns += now - wakeup_ts[next]

用户态每个窗口做差分：

CPUUtil    = delta(run_ns) / interval_ns
CtxPerMin  = delta(ctx) / interval_minutes
RunqWaitUs = delta(runq_ns) / delta(ctx) / 1000

对应代码：cpu.bpf.c 的 handle_switch / handle_wakeup，Go 侧是 collector.go。

11.2 I/O 延迟抖动 / 阻塞等待

唯一需要补充的事实：块层请求有两个稳定事件。

二者时间差就是一次块 I/O 的完成延迟。eBPF 在 issue 时按 (dev, sector) 存时间戳，complete 时配对结算。

inflight = issue - complete，就是当前在途请求数，近似反映设备队列压力。P99 用 log2 桶估计，不是保存每次请求的原始延迟。

对应代码：block.bpf.c 的 handle_issue / handle_complete，Go 侧是 io.go。

11.3 内存抖动 / OOM 风险

你已知：缺页是访问虚拟页时发现没有可用物理页映射，内核现场处理。

需要补充的事实：物理内存紧张时，内核有两类回收路径。

eBPF 盯直接回收：

mm_vmscan_direct_reclaim_begin:
  start[pid] = now

mm_vmscan_direct_reclaim_end:
  direct_reclaim_count++
  direct_reclaim_ns += now - start[pid]

mm_vmscan_kswapd_wake:
  kswapd_wakes++

为什么 direct reclaim 是强信号：它说明“想要内存的线程拿不到足够空闲页，只能自己同步回收”。这不是单纯低水位，而是已经进入业务路径的阻塞成本。

当前 detector 的触发条件是系统级的：

MemAvailablePct < threshold
连续 sustain 窗口

触发后 pickCulprit() 才从 snap.Procs 里选主要贡献者：优先 direct reclaim 次数，其次 major fault。major/minor fault 不是 eBPF 采集，而是 Go 侧低频读取 /proc/<pid>/stat 差分；MemAvailable 来自 /proc/meminfo。

对应代码：mem.bpf.c 的 handle_direct_begin / handle_direct_end / handle_kswapd_wake，Go 侧是 mem.go。

11.4 锁竞争 / off-CPU 阻塞

你已知：mutex_lock 拿不到锁，线程会睡眠，等持锁者释放后被唤醒。

需要补充的事实：sched_switch 的 prev_state 区分“被抢占”和“主动阻塞”。

eBPF 逻辑：

sched_switch, prev_state != 0:
  offcpu_start[prev] = { now, stackid }

sched_switch, next 上 CPU:
  dur = now - offcpu_start[next]
  lock_stats[next].offcpu_ns += dur
  lock_stats[next].offcpu_count++

sched_wakeup:
  lock_stats[wakee].last_waker = current_tid

Go 侧拿到三类证据：

注意：当前 detector 只看 OffcpuRatio >= threshold 连续窗口；是否归类为“锁竞争”，是在 rca.BuildLockReport() 里通过阻塞栈符号二次判断。没有命中锁符号时，报告会降级为“长时间阻塞等待”。

对应代码：lock.bpf.c 的 handle_switch / handle_wakeup，Go 侧是 lock.go。

11.5 系统调用热点

你已知：read()/write()/fsync() 等 syscall 是用户态陷入内核的边界。

eBPF 使用通用 raw syscall tracepoint：

raw_syscalls:sys_enter:
  start[tid] = { now, syscall_nr }

raw_syscalls:sys_exit:
  dur = now - start[tid].ts
  syscall_stats[(tgid, nr)].count++
  syscall_stats[(tgid, nr)].total_ns += dur
  syscall_stats[(tgid, nr)].max_ns = max(max_ns, dur)  // best-effort

用户态窗口指标：

CallsPerSec    = delta(count) / interval
AvgLatUs       = delta(total_ns) / delta(count) / 1000
TotalMsPerSec  = delta(total_ns) / interval / 1e6

当前 detector 的触发条件是二选一：

CallsPerSec >= threshold       // 默认 10000 次/秒
或 TotalMsPerSec >= 300         // 单个 syscall 每秒累计占用超过 300ms

AvgLatUs >= 1000 不是触发条件，而是 RCA 分类条件：触发后如果平均单次耗时超过 1ms，就报告为“高耗时系统调用热点”；否则报告为“高频系统调用热点”。

对应代码：syscall.bpf.c 的 handle_enter / handle_exit，Go 侧是 syscall.go。

11.6 五场景对比总表

共性：内核态只做聚合计数，用户态按窗口差分，再由 detector 判定持续异常。锁场景额外调用 bpf_get_stackid 抓阻塞栈，这是相对更贵的操作，但只在阻塞切出路径执行。

11.7 一次 write() 可能触发多个探针

用户态 write(fd, buf, len)
         |
         v
raw_syscalls:sys_enter         -> syscall 热点开始计时
         |
         | 可能缺页 / 分配页
         |   -> direct_reclaim_begin/end
         |
         | 可能提交块 I/O
         |   -> block_rq_issue
         |   -> block_rq_complete
         |
         | 可能等锁 / 等 I/O 睡眠
         |   -> sched_switch(prev_state != 0)
         |   -> sched_wakeup
         |
         | 调度切换穿插发生
         |   -> sched_switch 统计 CPU run_ns / ctx
         |
raw_syscalls:sys_exit          -> syscall 热点结算耗时
         |
         v
返回用户态

这些探针彼此独立，不共享逻辑，只是从不同内核层面观察同一次业务行为。最终 RCA 依靠 evidence chain 把 CPU、I/O、内存、锁、syscall 的局部证据组织成根因判断。

12. main.go：用户态总控逻辑

cmd/ebpf-rca/main.go 本身不直接分析内核事件，它是 orchestrator：

命令行参数
  → 选择场景 runXXX
  → 初始化 collector / detector
  → 预热 Poll 建立差分基线
  → runLoop 周期采样
  → collector.Poll → detector.Detect → rca.BuildXXXReport → handler
  → Ctrl-C / SIGTERM / duration 到期退出

参数解析

main() 先解析：

thresholdFor() 给每类场景默认阈值。syscall 场景默认是 10000 次/秒。

handler：每条诊断报告如何处理

handler 的类型是：

type handler func(schema.AnomalyReport)

它处理的是一条完整 AnomalyReport，不是单条 evidence：

• 未设置 --report：立刻用 output.Write 按 JSON/YAML/Markdown 输出
• 设置 --report：先 agg.Add(r) 聚合，程序退出后统一 agg.Render

context：把退出信号变成取消事件

ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
defer stop()

含义：收到 Ctrl-C(SIGINT) 或 SIGTERM 时，ctx.Done() 会被关闭。

runLoop 中：

select {
case <-ctx.Done():
    return
case <-deadline:
    return
case now := <-ticker.C:
    tick(now)
}

所以退出路径是：信号到达 → context 取消 → 采样循环返回 → defer col.Close() 卸载 eBPF 资源。

runSyscall 执行路径

系统调用性能分析对应：

case "syscall":
    err = runSyscall(ctx, cfg, h)

runSyscall 做四件事：

1. collector.NewSyscallCollector()：加载并挂载 syscall eBPF 程序
2. detector.NewSyscallDetector(cfg.threshold, cfg.sustain)：创建连续窗口检测器
3. col.Poll(cfg.interval)：预热一次，建立窗口差分基线
4. runLoop(...)：每个窗口执行采样、检测、RCA、输出

核心循环：

samples, err := col.Poll(cfg.interval)
for _, sig := range det.Detect(samples, now) {
    h(rca.BuildSyscallReport(sig))
}

窗口差分在 collector 中完成

BPF map 保存的是累计值，例如 syscall 场景的：

Count   = 累计调用次数
TotalNs = 累计耗时
MaxNs   = 历史最大单次耗时

collector 保存上一轮 prev。每次 Poll 读取当前 cur 后计算：

dCount := cur.Count - prev.Count
dTotal := cur.TotalNs - prev.TotalNs

再换算成窗口指标：

calls_per_sec   = dCount / interval
avg_lat_us      = dTotal / dCount
total_ms_per_sec = dTotal / interval

因此分工是：

为什么 runLoop 前要先 Poll 一次

第一次 Poll 的结果被丢弃：

_, _ = col.Poll(cfg.interval)

它的作用不是诊断，而是记录当前累计值到 prev。

如果不预热，第一次正式采样时 prev 为空，collector 会把 eBPF 程序加载以来的全部累计值当作第一个窗口增量，导致第一次窗口不干净。

预热后的时间线：

t0: eBPF 已挂载，map 开始累计
t0: Poll() 只建立 prev，丢弃样本
t1: ticker 触发，Poll() 得到 t0~t1 的差分
t2: ticker 触发，Poll() 得到 t1~t2 的差分

注意：当前速率计算使用传入的 cfg.interval，不是实测的 now - lastPoll。如果 Go 调度或系统负载导致 tick 延迟，速率会有轻微误差；更严谨的实现应记录真实采样时间差。

13. 关键设计原则

两态分离：内核态只做机械计数（零判断、零分支），全部"智力"（算指标、判阈值、定根因）在每秒 1 次的用户态循环。

注入是一次性的，不是每次 syscall 都注入：Go 启动时一次性把字节码加载、挂载好，之后就驻留在内核事件链上。后续每次 tracepoint 触发，直接函数指针跳转到 eBPF 程序，不经过 syscall。

OS:Windows11 wsl2 6.6.87.2-microsoft-standard-WSL2 Ubuntu 24.04.3 LTS

CPU: Intel Core i7 13620H 8 cores, 10 logic processors, AVX2

GPU:NVIDIA GeForce RTX 4060 Laptop

assignment1

https://github.com/stanford-cs149/asst1

prog1_mandelbrot_threads

给定了计算并生成以下称为mandelbrot_set图像的代码，其中计算一个像素的时间与这个像素的亮度成正比

可以sudo apt install feh后，使用feh <image-path> 查看生成的图像

给出的mandelbrotSerial.cpp实现了单线程的计算，我们需要在mandelbrotThread.cpp中修改workerThreadStart函数，使用std::thread加速这个过程

我们先采用朴素的分配方式，将空间从上到下分为线程数份，分别分配给每个线程执行

void workerThreadStart(WorkerArgs * const args) {

    // TODO FOR CS149 STUDENTS: Implement the body of the worker
    // thread here. Each thread should make a call to mandelbrotSerial()
    // to compute a part of the output image.  For example, in a
    // program that uses two threads, thread 0 could compute the top
    // half of the image and thread 1 could compute the bottom half.

    printf("Hello world from thread %d\n", args->threadId);

    unsigned int num = args->height / args->numThreads;
    unsigned int st = args->threadId * num, ed = st + num;
    if (args->threadId == args->numThreads - 1) ed = args->height;

    mandelbrotSerial(args->x0, args->y0, args->x1, args->y1, args->width, args->height, st, ed - st, args->maxIterations, args->output);
}

make后使用./mandelbort -t <线程数>运行得到线程数与加速比的关系如下 第一次用matplotlib画图显示中文字符调了我半天:(

有意思的是，在view1中，使用3个线程加速比反而降低了，观察view1图像，中间部分计算量明显大于两边的计算量，因而负载不均匀导致加速比降低

一种有效的方式是讲整个图像划分为若干块，每个块内使用我们第一次的方式，因为相邻部分计算量差距较小，这就保证了负载尽量均匀，这被称为分块+线程内连续行分配的策略

void workerThreadStart(WorkerArgs * const args) {

    // TODO FOR CS149 STUDENTS: Implement the body of the worker
    // thread here. Each thread should make a call to mandelbrotSerial()
    // to compute a part of the output image.  For example, in a
    // program that uses two threads, thread 0 could compute the top
    // half of the image and thread 1 could compute the bottom half.

    printf("Hello world from thread %d\n", args->threadId);

    static constexpr unsigned int BLOCKSIZE = 128;
    unsigned int blocks = args->height / BLOCKSIZE;
    for (unsigned int i = 0; i < blocks; i++) {
        unsigned int block_st = i * BLOCKSIZE, block_ed = block_st + BLOCKSIZE;
        if (i + 1 == blocks) block_ed = args->height;
        unsigned int block_len = block_ed - block_st, thread_len = block_len / args->numThreads;
        unsigned thread_st = block_st + args->threadId * thread_len, thread_ed = thread_st + thread_len;
        if (args->threadId + 1 == args->numThreads) thread_ed = block_ed;
        mandelbrotSerial(args->x0, args->y0, args->x1, args->y1, args->width, args->height, thread_st, thread_ed - thread_st, args->maxIterations, args->output);
    }
}

得到的结果如下：

对比发现生成两张图片的加速比都高于简单的空间划分，加速比的波动是由于块的大小这个参数造成的

prog2_vecintrin

要求我们使用intrinsics向量化重写代码，但是为了简化，使用的是cs149提供的库函数(事实上库函数也是标量模拟向量化)

阅读CS149intrin.cpp源码，其中每个函数功能如下

__cs149_mask _cs149_init_ones(int first=VECTOR_WIDTH)：返回一个前first位为1，其余位为0的mask向量

__cs149_mask _cs149_mask_not(__cs149_mask &maska)：将maska向量取反

__cs149_mask _cs149_mask_or(__cs149_mask &maska, __cs149_mask &maskb)：返回两个向量or运算后的向量

__cs149_mask _cs149_mask_and(__cs149_mask &maska, __cs149_mask &maskb)： 返回两个向量and运算后的向量

int _cs149_cntbits(__cs149_mask &maska) ： 返回maska中1的个数

对于接下来传入的mask参数，当某一位为1时表示对该位进行写入，为0时表示不写入

void _cs149_vset(__cs149_vec<T> &vecResult, T value, __cs149_mask &mask)：将value尝试写入向量每一位

void _cs149_vmove(__cs149_vec<T> &dest, __cs149_vec<T> &src, __cs149_mask &mask)：将src每一位尝试按位写入dest中

void _cs149_vload(__cs149_vec<T> &dest, T* src, __cs149_mask &mask)：将src数组每个位置按位尝试写入dest中

void _cs149_vstore(T* dest, __cs149_vec<T> &src, __cs149_mask &mask) ：将src每一位尝试写入数组dest中

void _cs149_vadd(__cs149_vec<T> &vecResult, __cs149_vec<T> &veca, __cs149_vec<T> &vecb, __cs149_mask &mask)：将veca和vecb每一位做加法之后尝试写入vecResult中，vsub，vmult，vdiv同理

void _cs149_vabs(__cs149_vec<T> &vecResult, __cs149_vec<T> &veca, __cs149_mask &mask)：将veca每一位取绝对值后，尝试写入vecResult中

void _cs149_vgt(__cs149_mask &maskResult, __cs149_vec<T> &veca, __cs149_vec<T> &vecb, __cs149_mask &mask)：将veca大于vecb按位比较得到的bool值尝试写入maskResult中，vlt，veq同理

void _cs149_hadd(__cs149_vec<T> &vecResult, __cs149_vec<T> &vec)：从0开始，计算相邻奇偶两项的和，直接写入vecResult的原位置中

void _cs149_interleave(__cs149_vec<T> &vecResult, __cs149_vec<T> &vec)：将vec中偶数索引放入vecResult前半部分，奇数索引放入后半部分

补全absVector

提供的代码已经实现了absVector主体部分，但是没有处理N % VECTOR_WIDTH != 0的情况，需要我们补全对余数的处理

因为每次计算答案不会发生变化，一种比较简单的方法是对于最后VECTOR_WIDTH个元素再向量化处理一次

// implementation of absSerial() above, but it is vectorized using CS149 intrinsics
void absVector(float* values, float* output, int N) {
  __cs149_vec_float x;
  __cs149_vec_float result;
  __cs149_vec_float zero = _cs149_vset_float(0.f);
  __cs149_mask maskAll, maskIsNegative, maskIsNotNegative;

//  Note: Take a careful look at this loop indexing.  This example
//  code is not guaranteed to work when (N % VECTOR_WIDTH) != 0.
//  Why is that the case?
  int i;
  for (i=0; i + VECTOR_WIDTH - 1 <N; i+=VECTOR_WIDTH) {

    // All ones
    maskAll = _cs149_init_ones();

    // All zeros
    maskIsNegative = _cs149_init_ones(0);

    // Load vector of values from contiguous memory addresses
    _cs149_vload_float(x, values+i, maskAll);               // x = values[i];

    // Set mask according to predicate
    _cs149_vlt_float(maskIsNegative, x, zero, maskAll);     // if (x < 0) {

    // Execute instruction using mask ("if" clause)
    _cs149_vsub_float(result, zero, x, maskIsNegative);      //   output[i] = -x;

    // Inverse maskIsNegative to generate "else" mask
    maskIsNotNegative = _cs149_mask_not(maskIsNegative);     // } else {

    // Execute instruction ("else" clause)
    _cs149_vload_float(result, values+i, maskIsNotNegative); //   output[i] = x; }

    // Write results back to memory
    _cs149_vstore_float(output+i, result, maskAll);
  }
  if (N % VECTOR_WIDTH == 0) return;
  i = N - VECTOR_WIDTH;
  maskAll = _cs149_init_ones();
  maskIsNegative = _cs149_init_ones(0);
  _cs149_vload_float(x, values + i, maskAll);
  _cs149_vlt_float(maskIsNegative, x, zero, maskAll);
  _cs149_vsub_float(result, zero, x, maskIsNegative);
  _cs149_mask_not(maskIsNegative);
  _cs149_vmove_float(result, x, maskIsNegative);
  _cs149_vstore_float(output, result, maskAll);
}

实现clampedExpVector

要求你使用intrinsics实现朴素的$values[i]$的$exponents[i]$次方计算，当结果与9.999999f取$min$

直接实现即可

void clampedExpVector(float* values, int* exponents, float* output, int N) {

  //
//   CS149 STUDENTS TODO: Implement your vectorized version of
  // clampedExpSerial() here.
  //
  // Your solution should work for any value of
  // N and VECTOR_WIDTH, not just when VECTOR_WIDTH divides N
  //
    __cs149_mask maskAll = _cs149_init_ones();
    __cs149_vec_int zero = _cs149_vset_int(0);
    __cs149_vec_int one = _cs149_vset_int(1);
    
    auto calc = [&] (int i) {
        __cs149_vec_int count;
        _cs149_vload_int(count, exponents + i, maskAll);
        __cs149_vec_float base;
        _cs149_vload_float(base, values + i, maskAll);
        __cs149_vec_float result = _cs149_vset_float(1.f);
        __cs149_mask Ispositive;
        _cs149_vgt_int(Ispositive, count, zero, maskAll);
        while (_cs149_cntbits(Ispositive) > 0) {    //while(count > 0)
            _cs149_vmult_float(result, result, base, Ispositive);   //if (count[i] > 0) result[i] *= values[i] 
            _cs149_vsub_int(count, count, one, maskAll);    //count--
            _cs149_vgt_int(Ispositive, count, zero, maskAll);
        }

        __cs149_vec_float bound = _cs149_vset_float(9.999999f);
        _cs149_vgt_float(Ispositive, result, bound, maskAll);   //if (result[i] > bound)
        _cs149_vmove_float(result, bound, Ispositive);  //result[i] = bound
        _cs149_vstore_float(output + i, result, maskAll); //output[i] = result[i] 
    };

    for (int i = 0; i + VECTOR_WIDTH - 1 < N; i += VECTOR_WIDTH) {
        calc(i);
    }
    if (N % VECTOR_WIDTH == 0) return;
    calc(N - VECTOR_WIDTH);
}

在工作集大小为10000时，测试结果如下

CLAMPED EXPONENT (required) 
Results matched with answer!
****************** Printing Vector Unit Statistics *******************
Vector Width:              4
Total Vector Instructions: 97070
Vector Utilization:        90.4%
Utilized Vector Lanes:     350981
Total Vector Lanes:        388280
************************ Result Verification *************************
Passed!!!

按照要求改动VECTOR_WIDTH参数，发现从2到16，向量利用率依次下降。当向量大小增大的时候，一个向量中出现分歧divergence的概率增加，导致部分向量空转，从而降低了平均向量利用率

arraySumVector(bonus)

要求实现数组求和的向量化版本，保证了数组长度一定是VECTOR_WIDTH的倍数，并且VECTOR_WIDTH为2的幂

$O(\frac{n}{VECTOR_WIDTH}+VECTOR_WIDTH)$的做法是trivial的，考虑$O(\frac{n}{VECTOR_WIDTH}+ \log_2{VECTOR_WIDTH})$的做法

在使用向量累加数组中的元素后，考虑怎么优化向量内部求和的过程，由于已经提供了hadd和interleave两个内置函数，考虑每次hadd之后再interleave，此后向量前半部分的和就是原向量的总和，这样我们只需要$O(log_2{VECTOR_WIDTh})$次迭代即可

// returns the sum of all elements in values
// You can assume N is a multiple of VECTOR_WIDTH
// You can assume VECTOR_WIDTH is a power of 2
float arraySumVector(float* values, int N) {
  
  //
  // CS149 STUDENTS TODO: Implement your vectorized version of arraySumSerial here
  //
    __cs149_vec_float acc = _cs149_vset_float(0.f);  
    __cs149_mask maskAll = _cs149_init_ones();

    for (int i=0; i<N; i+=VECTOR_WIDTH) {
        __cs149_vec_float vec_values;
        _cs149_vload_float(vec_values, values + i, maskAll);
        _cs149_vadd_float(acc, acc, vec_values, maskAll);
    }
    for (int i = 1; i < VECTOR_WIDTH; i <<=1) {
        _cs149_hadd_float(acc, acc);
        _cs149_interleave_float(acc, acc);
    }
    float *ptr = new float[VECTOR_WIDTH];
    _cs149_vstore_float(ptr, acc, maskAll);
    float result = ptr[0];
    delete ptr;
    return result;
}

prog3_mandelbrot_ispc

首先需要安装ispc, sudo snap install ispc即可

mandelbrot的ispc代码已经给出，我们只需要make后运行即可，结果如下

[mandelbrot serial]:            [140.509] ms
Wrote image file mandelbrot-serial.ppm
[mandelbrot ispc]:              [39.913] ms
Wrote image file mandelbrot-ispc.ppm
                                (3.52x speedup from ISPC)

发现实际只加速了3.5倍左右，与理论的AVX28倍加速相差较大，究其原因是mandelbrot计算中每个点的迭代次数不同，导致了divergence，拉低了有效利用率，同时对于内存的访问可能同样是性能的瓶颈

注意到此处，我们只使用了数据级并行，还可以使用多线程进行任务级并行，ispc提供了launch机制，是用户级线程池，相较std::thread开销更低，采取工作窃取方式进行调度，更为高效

虽然理论上当使用launch创建的任务数与逻辑处理器数相等的时候加速比最高，但是实际上更高的任务数尽管增加了线程通信的成本，却可能使得任务负载更加均衡，进而提高效率。本地测试在任务数为50左右最为高效

[mandelbrot serial]:            [140.531] ms
Wrote image file mandelbrot-serial.ppm
[mandelbrot ispc]:              [40.018] ms
Wrote image file mandelbrot-ispc.ppm
[mandelbrot multicore ispc]:    [4.202] ms
Wrote image file mandelbrot-task-ispc.ppm
                                (3.51x speedup from ISPC)
                                (33.45x speedup from task ISPC)

prog4_sqrt

已经完成了牛顿迭代法求解平方根倒数的ispc代码，其中需要求解的数据在$(0,3)$中，并且迭代次数与求解数据存在以下关系

最好/最坏加速比的构造

你需要构造两组输入的数据，使得ispc加速比最大/最小

这是随机生成状态下的加速比

[sqrt serial]:          [633.462] ms
[sqrt ispc]:            [168.335] ms
[sqrt task ispc]:       [13.948] ms
                                (3.76x speedup from ISPC)
                                (45.42x speedup from task ISPC)

为了使得加速比最大化，我们既需要让指令级并行加速，既尽可能让divergence发生少，同时也需要加速任务级并行，即让每个任务负载尽量平均

一个很好的想法是输入值全部相同，这样不会发生divergence，同时任务的负载也是相当均匀的

注意到为了尽量提高加速比，在其他部分耗时不变的情况下，我们需要提高计算在总时间中的占比，取所有值都接近于3.0即可，此时运算最多，加速比也最大

[sqrt serial]:          [2752.093] ms
[sqrt ispc]:            [573.343] ms
[sqrt task ispc]:       [50.224] ms
                                (4.80x speedup from ISPC)
                                (54.80x speedup from task ISPC)

要构造最坏加速比，我们不难联想到课程中的提问，只需要让8位向量中出现divergence，其他7位很快计算完毕后。空转，1位执行非常多的计算即可，使得CPU达到最坏利用率

所以考虑每隔8个数，构造一个为计算次数最多的接近于3.0，其它都为无需计算的1.0

[sqrt serial]:          [420.101] ms
[sqrt ispc]:            [547.059] ms
[sqrt task ispc]:       [49.483] ms
                                (0.77x speedup from ISPC)
                                (8.49x speedup from task ISPC

有意思的是，ISPC向量化之后反而比标量执行更慢了，这可能是因为向量化引入的额外指令开销（如掩码操作、数据打包等）而变得更慢

手写intrinsics实现牛顿迭代法求平方根倒数(bonus)

完成以下ISPC代码的AVX2实现

export void sqrt_ispc(uniform int N,
                      uniform float initialGuess,
                      uniform float values[],
                      uniform float output[])
{
    foreach (i = 0 ... N) {

        float x = values[i];
        float guess = initialGuess;

        float pred = abs(guess * guess * x - 1.f);

        while (pred > kThreshold) {
            guess = (3.f * guess - x * guess * guess * guess) * 0.5f;
            pred = abs(guess * guess * x - 1.f);
        }

        output[i] = x * guess;
        
    }
}

请输入文本

static void AVX2_invsqrt(int n, float initialGuess, float values[], float outputs[]) {
    __m256 vec_one = _mm256_set1_ps(1.0f);
    __m256 vec_three = _mm256_set1_ps(3.0f);
    __m256 vec_half = _mm256_set1_ps(0.5f);
    __m256 vec_neg = _mm256_set1_ps(-0.0f);
    __m256 vec_threshold = _mm256_set1_ps(kThreshold);

    auto calc = [&](int i) {
        __m256 vec_x = _mm256_loadu_ps(values + i);
        __m256 vec_guess = _mm256_set1_ps(initialGuess);

        __m256 vec_pred = _mm256_mul_ps(vec_guess, vec_guess);
        vec_pred = _mm256_mul_ps(vec_pred, vec_x);
        vec_pred = _mm256_sub_ps(vec_pred, vec_one);
        vec_pred = _mm256_andnot_ps(vec_neg, vec_pred);
        
        __m256 mask = _mm256_cmp_ps(vec_pred, vec_threshold, _CMP_GT_OQ);
        while (_mm_popcnt_u32(_mm256_movemask_ps(mask))) {
            __m256 vec_sub, new_guess;
            new_guess = _mm256_mul_ps(vec_guess, vec_three);
            vec_sub = _mm256_mul_ps(vec_guess, vec_guess);
            vec_sub = _mm256_mul_ps(vec_sub, vec_guess);
            vec_sub = _mm256_mul_ps(vec_sub, vec_x);
            new_guess = _mm256_sub_ps(new_guess, vec_sub);
            new_guess = _mm256_mul_ps(new_guess, vec_half);
            vec_guess = _mm256_blendv_ps(vec_guess, new_guess, mask);

            __m256 new_pred;
            new_pred = _mm256_mul_ps(vec_guess, vec_guess);
            new_pred = _mm256_mul_ps(new_pred, vec_x);
            new_pred = _mm256_sub_ps(new_pred, vec_one);
            new_pred = _mm256_andnot_ps(vec_neg, new_pred);
            vec_pred = _mm256_blendv_ps(vec_pred, new_pred, mask);

            mask = _mm256_cmp_ps(vec_pred, vec_threshold, _CMP_GT_OQ);
        }
        
        _mm256_storeu_ps(outputs + i, _mm256_mul_ps(vec_guess, vec_x));
    };
    for (int i = 0; i + 7 < n; i += 8) calc(i);
    if (n % 8 == 0) return;
    calc(n - 8);
}

实际性能如下：

[sqrt serial]:          [425.807] ms
[sqrt ispc]:            [541.254] ms
[sqrt AVX2]:            [520.926] ms
[sqrt task ispc]:       [53.460] ms
                                (0.79x speedup from ISPC)
                                (0.82x speedup from AVX2)
                                (7.96x speedup from task ISPC)

发现相较ISPC没有显著提升，所以没事别来写这一坨

prog5_saxpy

给了我们使用ISPC加速saxpy计算result=scale*X+Y，其中result,X,Y为$2\times10^7$大小的向量，scale为标量

运行后结果如下：

[saxpy serial]:         [10.404] ms     [28.644] GB/s   [3.845] GFLOPS
[saxpy ispc]:           [8.441] ms      [35.306] GB/s   [4.739] GFLOPS
[saxpy task ispc]:      [4.405] ms      [67.656] GB/s   [9.081] GFLOPS
                                (1.92x speedup from use of tasks)
                                (1.23x speedup from ISPC)
                                (2.36x speedup from task ISPC)

我们发现加速效果相当差，远低于理论加速。不难发现，每两次运算(一次乘法和加法)需要访问内存四次(读取X,读取Y,对result读取所有权，写入result)共32字节，这与每访问字节进行10至20次运算的理想访存计算比相差极大，所以性能瓶颈在内存访问上，而不是计算上，无法通过并行计算达到近线性的加速

附加题：尝试有效地加速该程序 不会:(

prog6_kmeans

K-Means算法实现了将一堆散乱的数据点分为k簇，所有数据点到其所属簇中心的距离平方和是一个局部最小值

给出你一段K_Means的正确但未优化的代码，要求自行找到性能热点并加速，要求至少达到2.1倍加速比

在main.cpp中去掉部分注释，本地生成数据，原始代码效率如下(运行时可能稍有波动)

Reading data.dat...
Running K-means with: M=1000000, N=100, K=3, epsilon=0.100000
[Total Time]: 6587.359 ms

在重复迭代直至收敛的过程中，执行了三个函数computeAssignments，computeCentroids，computeCost，使用课程提供的CycleTimer::currentSeconds发现耗时分别如下

Reading data.dat...
Running K-means with: M=1000000, N=100, K=3, epsilon=0.100000

computeAssignments: 4187.6ms
computeCentroids: 874.883ms
computeCost: 1277.58ms

assign_init: 28.4267ms assign_assign: 4158.83ms
centr_zero: 0.011599ms centr_sum: 874.803ms centr_compute: 0.003952ms
cost_zero: 0.008803ms cost_sum: 1277.49ms cost_update: 0.014024ms
[Total Time]: 6340.125 ms

发现性能瓶颈在computeAssignments中的分配部分，源代码如下

  for (int k = args->start; k < args->end; k++) {
    for (int m = 0; m < args->M; m++) {
      double d = dist(&args->data[m * args->N],
                      &args->clusterCentroids[k * args->N], args->N);
      if (d < minDist[m]) {
        minDist[m] = d;
        args->clusterAssignments[m] = k;
      }
    }
  }

考虑对这部分进行优化，阅读发现是对于每一个点，求离k个簇中哪个簇距离最近并更新

我们发现这k次更新具有并行性，可以考虑使用k个线程

std::mutex mtx;

void assign(double *minDist, WorkerArgs *const args, int k) {
    for (int m = 0; m < args->M; m++) {
      mtx.lock();
      double d = dist(&args->data[m * args->N],
                      &args->clusterCentroids[k * args->N], args->N);
      if (d < minDist[m]) {
        minDist[m] = d;
        args->clusterAssignments[m] = k;
      }
      mtx.unlock();
    }
}

double assign_init = 0, assign_assign = 0;
void computeAssignments(WorkerArgs *const args) {
  double *minDist = new double[args->M];
  
  // Initialize arrays
  double timer; Set_timer(timer);
  for (int m =0; m < args->M; m++) {
    minDist[m] = 1e30;
    args->clusterAssignments[m] = -1;
  }
  assign_init += Get_timer(timer);

  // Assign datapoints to closest centroids
  Set_timer(timer);
  static constexpr int SIZE = 3;
  std::thread workers[SIZE];
  for (int k = args->start + 1; k < args->end; k++) {
    workers[k] = std::thread(assign, minDist, args, k);
  }
  assign(minDist, args, args->start);
  for (int k = args->start + 1; k < args->end; k++) {
    workers[k].join();
  }
  assign_assign += Get_timer(timer);

  delete[] minDist;
}

注意会产生多个线程对于minDist和args->clusterAssignments的更新，需要上锁

效率如下：(我自己都要蚌埠住了)

Reading data.dat...
Running K-means with: M=1000000, N=100, K=3, epsilon=0.100000

computeAssignments: 10419.6ms
computeCentroids: 843.017ms
computeCost: 1184.35ms

assign_init: 25.4263ms assign_assign: 10393.9ms
centr_zero: 0.009089ms centr_sum: 842.949ms centr_compute: 0.004045ms
cost_zero: 0.007699ms cost_sum: 1184.28ms cost_update: 0.009066ms
[Total Time]: 12447.063 ms

效率严重下降，因为加锁的代价大于线程的收益

于是考虑将m个任务分配给多个线程进行并行计算，这样保证了同一个资源只会被一个线程访问

void assign(double *minDist, WorkerArgs *const args, int l, int r) {
    for (int k = args->start; k < args->end; k++) {
        for (int m = l; m < r; m++) {
        double d = dist(&args->data[m * args->N],
                        &args->clusterCentroids[k * args->N], args->N);
        if (d < minDist[m]) {
            minDist[m] = d;
            args->clusterAssignments[m] = k;
        }
        }         
    }
}

double assign_init = 0, assign_assign = 0;
void computeAssignments(WorkerArgs *const args) {
  double *minDist = new double[args->M];
  
  // Initialize arrays
  double timer; Set_timer(timer);
  for (int m =0; m < args->M; m++) {
    minDist[m] = 1e30;
    args->clusterAssignments[m] = -1;
  }
  assign_init += Get_timer(timer);

  // Assign datapoints to closest centroids
  Set_timer(timer);
  static constexpr int THREADS = 32;
  std::thread workers[THREADS];
  int len = args->M / THREADS;
  for (int i = 1; i < THREADS; i++) {
      int l = i * len, r = l + len;
      if (i == THREADS - 1) r = args->M;
      workers[i] = std::thread(assign, minDist, args, l, r);
  }
  int l = 0, r = len; 
  assign(minDist, args, l, r);
  for (int i = 1; i < THREADS; i++) workers[i].join();
  assign_assign += Get_timer(timer);

  delete[] minDist;
}

结果如下，刚好达到了要求的加速比，代码的其他部分也可以类似地并行化来提高效率，但是题目只要求了并行化一处

Reading data.dat...
Running K-means with: M=1000000, N=100, K=3, epsilon=0.100000

computeAssignments: 1067.84ms
computeCentroids: 872.724ms
computeCost: 1160.83ms

assign_init: 25.0641ms assign_assign: 1042.34ms
centr_zero: 0.009931ms centr_sum: 872.655ms centr_compute: 0.004261ms
cost_zero: 0.008192ms cost_sum: 1160.75ms cost_update: 0.012866ms
[Total Time]: 3101.462 ms

OS:Windows11 wsl2 6.6.87.2-microsoft-standard-WSL2 Ubuntu 24.04.3 LTS

CPU: Intel Core i7 13620H 8 cores, 10 logic processors, AVX2

GPU:NVIDIA GeForce RTX 4060 Laptop

assignment2

这一部分要求你补全一个类似于ISPC的任务系统，其余部分已经完成，你需要完成负载分配部分

你需要完成无依赖和有依赖的任务系统，并且要用每次创建线程，使用线程池且线程自旋，使用线程池且线程休眠三种方式实现

无依赖的任务系统

每次创建线程

这是trivial的，每次创建线程执行任务即可，为了平均负载，每当有空闲进程时就取出下一个任务来给该线程执行

注意当前执行到了哪一个进程这个变量会被多个线程使用，需要声明为原子变量

//tasksys.h
class TaskSystemParallelSpawn: public ITaskSystem {
    public:
        TaskSystemParallelSpawn(int num_threads);
        ~TaskSystemParallelSpawn() override;
        const char* name();
        void run(IRunnable* runnable, int num_total_tasks);
        TaskID runAsyncWithDeps(IRunnable* runnable, int num_total_tasks,
                                const std::vector<TaskID>& deps);
        void sync();
    private:
        int Num_Threads;
        std::atomic <int> task_ptr;
        std::thread *thread_ptr;
};

//tasksys.cpp
const char* TaskSystemParallelSpawn::name() {
    return "Parallel + Always Spawn";
}

TaskSystemParallelSpawn::TaskSystemParallelSpawn(int num_threads) 
    : ITaskSystem(num_threads), 
      Num_Threads(num_threads), 
      thread_ptr(new std::thread[num_threads]),
      task_ptr(0) {

    //
    // TODO: CS149 student implementations may decide to perform setup
    // operations (such as thread pool construction) here.
    // Implementations are free to add new class member variables
    // (requiring changes to tasksys.h).
    //
}

TaskSystemParallelSpawn::~TaskSystemParallelSpawn() {
    delete[] thread_ptr;
}

void TaskSystemParallelSpawn::run(IRunnable* runnable, int num_total_tasks){

    //
    // TODO: CS149 students will modify the implementation of this
    // method in Part A.  The implementation provided below runs all
    // tasks sequentially on the calling thread.
    //
    task_ptr = 0;
    auto work = [&]() {
        while(1) {
            int task_id = task_ptr.fetch_add(1);
            if (task_id >= num_total_tasks) break;
            runnable->runTask(task_id, num_total_tasks);
        }
    };

    for (int i = 0; i < Num_Threads; i++) {
        thread_ptr[i] = std::thread(work);
    }
    for (int i = 0; i < Num_Threads; i++) {
        thread_ptr[i].join();
    }
}

TaskID TaskSystemParallelSpawn::runAsyncWithDeps(IRunnable* runnable, int num_total_tasks,
                                                 const std::vector<TaskID>& deps) {
    // You do not need to implement this method.
    return 0;
}

void TaskSystemParallelSpawn::sync() {
    // You do not need to implement this method.
    return;
}

自旋线程池

每次都创建线程会产生额外的开销，为了减少开销，可以在任务系统被创建的时候就创建线程，在需要的时候执行任务，否则自旋，当任务系统调用析构函数的时候，结束所有线程

//tasksys.h
class TaskSystemParallelThreadPoolSpinning: public ITaskSystem {
    public:
        TaskSystemParallelThreadPoolSpinning(int num_threads);
        ~TaskSystemParallelThreadPoolSpinning();
        const char* name();
        void run(IRunnable* runnable, int num_total_tasks);
        TaskID runAsyncWithDeps(IRunnable* runnable, int num_total_tasks,
                                const std::vector<TaskID>& deps);
        void sync();
    private:
        int Num_Threads;
        std::thread *thread_ptr;
        IRunnable *task;
        int task_num;
        std::atomic <bool> end;
        std::atomic<int> task_ptr, task_done;
        std::mutex mtx;
};

//tasksys.cpp
const char* TaskSystemParallelThreadPoolSpinning::name() {
    return "Parallel + Thread Pool + Spin";
}

TaskSystemParallelThreadPoolSpinning::TaskSystemParallelThreadPoolSpinning(int num_threads)
    : ITaskSystem(num_threads),
      Num_Threads(num_threads),
      thread_ptr(new std::thread[num_threads]),
      task(nullptr), 
      task_num(0), 
      task_ptr(0),
      end(false) {

    //
    // TODO: CS149 student implementations may decide to perform setup
    // operations (such as thread pool construction) here.
    // Implementations are free to add new class member variables
    // (requiring changes to tasksys.h).
    //

    auto work = [&]() {
        while (1) {
            if (end) break;
            int task_id = -1; {
                std::unique_lock <std::mutex> lock(mtx);
                if (task_ptr < task_num) {
                    task_id = task_ptr;
                    task_ptr++;
                }
            }

            if (task_id != -1) {
                task->runTask(task_id, task_num);
                task_done.fetch_add(1);
            }
        }
    };

    for (int i = 0; i < num_threads; i++) {
        thread_ptr[i] = std::thread(work);
    }
}

TaskSystemParallelThreadPoolSpinning::~TaskSystemParallelThreadPoolSpinning() {
    end = true;
    for (int i = 0; i < Num_Threads; i++) {
        thread_ptr[i].join();
    }
    delete[] thread_ptr;
}

void TaskSystemParallelThreadPoolSpinning::run(IRunnable* runnable, int num_total_tasks) {


    //
    // TODO: CS149 students will modify the implementation of this
    // method in Part A.  The implementation provided below runs all
    // tasks sequentially on the calling thread.
    //
    mtx.lock();
    task = runnable;
    task_num = num_total_tasks;
    task_ptr = 0;
    task_done = 0;
    mtx.unlock();
    while (task_done < task_num) {}
}

TaskID TaskSystemParallelThreadPoolSpinning::runAsyncWithDeps(IRunnable* runnable, int num_total_tasks,
                                                              const std::vector<TaskID>& deps) {
    // You do not need to implement this method.
    return 0;
}

void TaskSystemParallelThreadPoolSpinning::sync() {
    // You do not need to implement this method.
    return;
}

休眠线程池

当一个线程在没有任务自旋的时候，仍然会占用CPU，考虑在没有剩余任务的时候让线程自旋

C++提供了条件变量condition_variable来进行控制

对于一个条件变量，可以通过其成员函数wait(std::unique_lock, pred) 使得拥有指定的互斥锁的线程休眠，直到接到通知并且pred为true(如果不设置pred，可能出现丢失唤醒和虚假唤醒)；通过成员函数notify_all/one 来通知该条件变量的所有/随机一个线程

//tasksys.h
class TaskSystemParallelThreadPoolSleeping: public ITaskSystem {
    public:
        TaskSystemParallelThreadPoolSleeping(int num_threads);
        ~TaskSystemParallelThreadPoolSleeping();
        const char* name();
        void run(IRunnable* runnable, int num_total_tasks);
        TaskID runAsyncWithDeps(IRunnable* runnable, int num_total_tasks,
                                const std::vector<TaskID>& deps);
        void sync();
    private:
        int Num_Threads;
        std::thread *thread_ptr;
        IRunnable *task;
        int task_num;
        std::atomic <bool> end;
        std::atomic<int> task_ptr, task_done;
        std::mutex mtx;
        std::condition_variable cond;
};

//tasksys.cpp
const char* TaskSystemParallelThreadPoolSleeping::name() {
    return "Parallel + Thread Pool + Sleep";
}

TaskSystemParallelThreadPoolSleeping::TaskSystemParallelThreadPoolSleeping(int num_threads)
    : ITaskSystem(num_threads),
      Num_Threads(num_threads),
      thread_ptr(new std::thread[num_threads]),
      task(nullptr),
      end(false), 
      task_num(0),
      task_done(0),
      task_ptr(0) {
    //
    // TODO: CS149 student implementations may decide to perform setup
    // operations (such as thread pool construction) here.
    // Implementations are free to add new class member variables
    // (requiring changes to tasksys.h).
    //

    auto work = [&]() {
        while (1) {
            int task_id = -1; {
                std::unique_lock <std::mutex> lock(mtx);
                cond.wait(lock, [&]() {
                    return (task_ptr < task_num) || end;
                });
                if (end) break;
                task_id = task_ptr;
                task_ptr++;             
            }

            if (task_id != -1) {
                task->runTask(task_id, task_num);
                task_done.fetch_add(1);
            }
        }
    };
    for (int i = 0; i < Num_Threads; i++) {
        thread_ptr[i] = std::thread(work);
    }
}

TaskSystemParallelThreadPoolSleeping::~TaskSystemParallelThreadPoolSleeping() {
    //
    // TODO: CS149 student implementations may decide to perform cleanup
    // operations (such as thread pool shutdown construction) here.
    // Implementations are free to add new class member variables
    // (requiring changes to tasksys.h).
    //
    end = 1;
    cond.notify_all();
    for (int i = 0; i < Num_Threads; i++) {
        thread_ptr[i].join();
    }
}

void TaskSystemParallelThreadPoolSleeping::run(IRunnable* runnable, int num_total_tasks) {


    //
    // TODO: CS149 students will modify the implementation of this
    // method in Parts A and B.  The implementation provided below runs all
    // tasks sequentially on the calling thread.
    //
    mtx.lock();
    task = runnable;
    task_num = num_total_tasks;
    task_done = 0;
    task_ptr = 0;
    mtx.unlock();
    cond.notify_all();
    while (task_done < task_num) {}

}

TaskID TaskSystemParallelThreadPoolSleeping::runAsyncWithDeps(IRunnable* runnable, int num_total_tasks,
                                                    const std::vector<TaskID>& deps) {


    //
    // TODO: CS149 students will implement this method in Part B.
    //

    return 0;
}

void TaskSystemParallelThreadPoolSleeping::sync() {

    //
    // TODO: CS149 students will modify the implementation of this method in Part B.
    //

    return;
}

测试结果如下

katyusha@Katyusha-PC:~/lesson/CS149/asst2/part_a$ python3 ../tests/run_test_harness.py
runtasks_ref
Linux x86_64
================================================================================
Running task system grading harness... (11 total tests)
  - Detected CPU with 16 execution contexts
  - Task system configured to use at most 16 threads
================================================================================
================================================================================
Executing test: super_super_light...
Reference binary: ./runtasks_ref_linux
Results for: super_super_light
                                        STUDENT   REFERENCE   PERF?
[Serial]                                3.047     3.205       0.95  (OK)
[Parallel + Always Spawn]               187.19    185.967     1.01  (OK)
[Parallel + Thread Pool + Spin]         17.331    24.842      0.70  (OK)
[Parallel + Thread Pool + Sleep]        49.395    50.039      0.99  (OK)
================================================================================
Executing test: super_light...
Reference binary: ./runtasks_ref_linux
Results for: super_light
                                        STUDENT   REFERENCE   PERF?
[Serial]                                40.591    39.736      1.02  (OK)
[Parallel + Always Spawn]               192.036   192.494     1.00  (OK)
[Parallel + Thread Pool + Spin]         16.801    28.911      0.58  (OK)
[Parallel + Thread Pool + Sleep]        50.339    49.974      1.01  (OK)
================================================================================
Executing test: ping_pong_equal...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_equal
                                        STUDENT   REFERENCE   PERF?
[Serial]                                647.781   650.243     1.00  (OK)
[Parallel + Always Spawn]               226.69    232.931     0.97  (OK)
[Parallel + Thread Pool + Spin]         127.354   151.776     0.84  (OK)
[Parallel + Thread Pool + Sleep]        141.546   151.333     0.94  (OK)
================================================================================
Executing test: ping_pong_unequal...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_unequal
                                        STUDENT   REFERENCE   PERF?
[Serial]                                1190.3    1201.024    0.99  (OK)
[Parallel + Always Spawn]               296.642   301.453     0.98  (OK)
[Parallel + Thread Pool + Spin]         191.766   201.452     0.95  (OK)
[Parallel + Thread Pool + Sleep]        205.871   201.991     1.02  (OK)
================================================================================
Executing test: recursive_fibonacci...
Reference binary: ./runtasks_ref_linux
Results for: recursive_fibonacci
                                        STUDENT   REFERENCE   PERF?
[Serial]                                563.32    1044.844    0.54  (OK)
[Parallel + Always Spawn]               96.153    147.336     0.65  (OK)
[Parallel + Thread Pool + Spin]         95.011    161.128     0.59  (OK)
[Parallel + Thread Pool + Sleep]        95.246    136.351     0.70  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop
                                        STUDENT   REFERENCE   PERF?
[Serial]                                321.704   364.809     0.88  (OK)
[Parallel + Always Spawn]               902.166   959.155     0.94  (OK)
[Parallel + Thread Pool + Spin]         109.294   148.513     0.74  (OK)
[Parallel + Thread Pool + Sleep]        233.708   260.56      0.90  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fewer_tasks...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fewer_tasks
                                        STUDENT   REFERENCE   PERF?
[Serial]                                355.836   368.551     0.97  (OK)
[Parallel + Always Spawn]               956.475   954.91      1.00  (OK)
[Parallel + Thread Pool + Spin]         152.932   179.352     0.85  (OK)
[Parallel + Thread Pool + Sleep]        258.914   261.421     0.99  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fan_in...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fan_in
                                        STUDENT   REFERENCE   PERF?
[Serial]                                184.691   187.97      0.98  (OK)
[Parallel + Always Spawn]               129.168   125.984     1.03  (OK)
[Parallel + Thread Pool + Spin]         39.776    45.638      0.87  (OK)
[Parallel + Thread Pool + Sleep]        51.235    53.255      0.96  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_reduction_tree...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_reduction_tree
                                        STUDENT   REFERENCE   PERF?
[Serial]                                185.884   190.249     0.98  (OK)
[Parallel + Always Spawn]               57.856    58.765      0.98  (OK)
[Parallel + Thread Pool + Spin]         38.416    38.12       1.01  (OK)
[Parallel + Thread Pool + Sleep]        41.4      38.552      1.07  (OK)
================================================================================
Executing test: spin_between_run_calls...
Reference binary: ./runtasks_ref_linux
Results for: spin_between_run_calls
                                        STUDENT   REFERENCE   PERF?
[Serial]                                219.686   373.554     0.59  (OK)
[Parallel + Always Spawn]               112.957   191.493     0.59  (OK)
[Parallel + Thread Pool + Spin]         192.487   238.134     0.81  (OK)
[Parallel + Thread Pool + Sleep]        122.142   191.913     0.64  (OK)
================================================================================
Executing test: mandelbrot_chunked...
Reference binary: ./runtasks_ref_linux
Results for: mandelbrot_chunked
                                        STUDENT   REFERENCE   PERF?
[Serial]                                273.413   274.303     1.00  (OK)
[Parallel + Always Spawn]               30.291    28.085      1.08  (OK)
[Parallel + Thread Pool + Spin]         25.06     26.769      0.94  (OK)
[Parallel + Thread Pool + Sleep]        26.543    25.636      1.04  (OK)
================================================================================
Overall performance results
[Serial]                                : All passed Perf
[Parallel + Always Spawn]               : All passed Perf
[Parallel + Thread Pool + Spin]         : All passed Perf
[Parallel + Thread Pool + Sleep]        : All passed Perf

有依赖的任务系统

要求你在休眠线程池功能基础上，实现runAsyncWithDeps函数，该函数相较于run还传入了一个std::vector<TaskID>参数，用来表示前置需要完成的任务集合，返回值为该任务的TaskID。该任务与run中的任务异步执行，直到调用sync()函数，阻塞主线程直到所有的依赖任务都已经完成

可以将run看做一个特殊的无依赖的任务，在对其调用runAsyncWithDeps后立即sync()同步

我们使用了队列来维护可执行的任务(即所有前置任务都已经完成的任务)，每次一个线程都尝试在队列中取出任务进行执行。

为了维护任务间的依赖关系，我们对每个任务都维护了一个suf集合，用来表示依赖于该任务的后继。当一个任务子任务全部完成时，就更新其所有后继的状态，若一个后继的前置任务全部完成，就将该后继加入队列；当申请一个新的任务时，对于其未完成的前置任务，尝试更新其suf集合

在实现上存在诸多细节，比如使用vector的话，原本有效的迭代器可能因为其他线程操作扩容而导致失效造成悬空引用，可以使用deque，unordered_map数据结构进行替代，或者采用下标索引；在效率方面尽量少使用互斥锁，多使用原子变量并且在必须使用互斥锁的时候只进行简单的标记，记录等操作

//tasksys.h
class TaskSystemParallelThreadPoolSleeping: public ITaskSystem {
    public:
        TaskSystemParallelThreadPoolSleeping(int num_threads);
        ~TaskSystemParallelThreadPoolSleeping();
        const char* name();
        void run(IRunnable* runnable, int num_total_tasks);
        TaskID runAsyncWithDeps(IRunnable* runnable, int num_total_tasks,
                                const std::vector<TaskID>& deps);
        void sync();
    private:
        std::thread *thread_ptr;
        IRunnable *task;
        int Num_threads;
        int task_done = 0;
        std::queue<TaskID> task_que;
        struct Task {
            std::vector <int> suf;
            IRunnable *task;
            std::atomic<int> task_ptr{0}, task_done{0}, pre_done{0};
            int task_num, pre_cnt;
            Task() {}
            Task(IRunnable *T, int Task_num, int Pre_cnt) 
                : task(T), 
                  task_num(Task_num),
                  pre_cnt(Pre_cnt) {

            }
        };
        std::vector <Task*> task_vec;
        std::mutex mtx;
        std::condition_variable work_cv, sync_cv;
        bool end = false;
};

//tasksys.cpp

/*
 * ================================================================
 * Parallel Thread Pool Sleeping Task System Implementation
 * ================================================================
 */

const char* TaskSystemParallelThreadPoolSleeping::name() {
    return "Parallel + Thread Pool + Sleep";
}

TaskSystemParallelThreadPoolSleeping::TaskSystemParallelThreadPoolSleeping(int num_threads)
    : ITaskSystem(num_threads),
      Num_threads(num_threads),
      thread_ptr(new std::thread[num_threads]),
      end(false),
      task_done(0) {
    //
    // TODO: CS149 student implementations may decide to perform setup
    // operations (such as thread pool construction) here.
    // Implementations are free to add new class member variables
    // (requiring changes to tasksys.h).
    //
    auto work = [&]() {
        while (1) {
            int task_id = -1, subtask_id = -1;
            Task *ptr = nullptr; {
                std::unique_lock <std::mutex> lock(mtx);
                work_cv.wait(lock, [&]() {
                    return (!task_que.empty()) || end;
                });
                if (end && task_que.empty()) break;
                task_id = task_que.front();
                ptr = task_vec[task_id];
                if (ptr->task_ptr >= ptr->task_num) {
                    task_que.pop();
                    continue;
                }
            }

            if (ptr != nullptr) {
                while (1) {
                    subtask_id = ptr->task_ptr.fetch_add(1);
                    if (subtask_id >= ptr->task_num) break; 
                    ptr->task->runTask(subtask_id, ptr->task_num); 
                    int done = ptr->task_done.fetch_add(1) + 1; 
                    if (done == ptr->task_num){
                        std::unique_lock <std::mutex> lock(mtx);
                        ++task_done;
                        for (const auto &idx : ptr->suf) {
                            Task *_ptr = task_vec[idx];
                            if (++_ptr->pre_done == _ptr->pre_cnt) {
                                task_que.push(idx);
                                work_cv.notify_all();
                            }    
                        }
                        sync_cv.notify_all();
                    }                    
                }
            }
        }
    };
    for (int i = 0; i < Num_threads; i++) {
        thread_ptr[i] = std::thread(work);
    }
}

TaskSystemParallelThreadPoolSleeping::~TaskSystemParallelThreadPoolSleeping() {
    //
    // TODO: CS149 student implementations may decide to perform cleanup
    // operations (such as thread pool shutdown construction) here.
    // Implementations are free to add new class member variables
    // (requiring changes to tasksys.h).
    //
    std::unique_lock <std::mutex> lock(mtx);
    end = 1;
    lock.unlock();
    work_cv.notify_all();
    for (int i = 0; i < Num_threads; i++) {
        thread_ptr[i].join();
    }
    delete[] thread_ptr;
    for (auto ptr : task_vec) {
        delete ptr;
    }
}

void TaskSystemParallelThreadPoolSleeping::run(IRunnable* runnable, int num_total_tasks) {


    //
    // TODO: CS149 students will modify the implementation of this
    // method in Parts A and B.  The implementation provided below runs all
    // tasks sequentially on the calling thread.
    //
    runAsyncWithDeps(runnable, num_total_tasks, std::vector<TaskID>{}); 
    sync();
}

TaskID TaskSystemParallelThreadPoolSleeping::runAsyncWithDeps(IRunnable* runnable, int num_total_tasks,
                                                    const std::vector<TaskID>& deps) {


    //
    // TODO: CS149 students will implement this method in Part B.
    //
    std::unique_lock <std::mutex> lock(mtx);
    int id = static_cast <int> (task_vec.size());
    int pre = 0;
    for (const auto &idx : deps) {
        Task *ptr = task_vec[idx];
        if (ptr->task_done < ptr->task_num) {
            pre++;
            ptr->suf.push_back(id);
        }
    }
    Task *ptr = new Task(runnable, num_total_tasks, pre);
    task_vec.push_back(ptr);

    if (pre == 0) {
        task_que.push(id);
        work_cv.notify_all();
    }

    return id;
}

void TaskSystemParallelThreadPoolSleeping::sync() {

    //
    // TODO: CS149 students will modify the implementation of this method in Part B.
    //
    std::unique_lock <std::mutex> lock(mtx);
    sync_cv.wait(lock, [&]() {
        return task_done == static_cast<int>(task_vec.size());
    });
}

评测结果如下

katyusha@Katyusha-PC:~/lesson/CS149/asst2/part_b$ python3 ../tests/run_test_harness.py -a
runtasks_ref
Linux x86_64
================================================================================
Running task system grading harness... (22 total tests)
  - Detected CPU with 16 execution contexts
  - Task system configured to use at most 16 threads
================================================================================
================================================================================
Executing test: super_super_light...
Reference binary: ./runtasks_ref_linux
Results for: super_super_light
                                        STUDENT   REFERENCE   PERF?
[Serial]                                3.374     3.232       1.04  (OK)
[Parallel + Always Spawn]               3.294     143.047     0.02  (OK)
[Parallel + Thread Pool + Spin]         3.297     32.456      0.10  (OK)
[Parallel + Thread Pool + Sleep]        34.289    49.513      0.69  (OK)
================================================================================
Executing test: super_super_light_async...
Reference binary: ./runtasks_ref_linux
Results for: super_super_light_async
                                        STUDENT   REFERENCE   PERF?
[Serial]                                3.304     3.167       1.04  (OK)
[Parallel + Always Spawn]               3.28      141.914     0.02  (OK)
[Parallel + Thread Pool + Spin]         3.294     25.471      0.13  (OK)
[Parallel + Thread Pool + Sleep]        9.923     49.523      0.20  (OK)
================================================================================
Executing test: super_light...
Reference binary: ./runtasks_ref_linux
Results for: super_light
                                        STUDENT   REFERENCE   PERF?
[Serial]                                43.447    40.952      1.06  (OK)
[Parallel + Always Spawn]               43.668    151.303     0.29  (OK)
[Parallel + Thread Pool + Spin]         43.431    35.089      1.24  (OK)
[Parallel + Thread Pool + Sleep]        60.807    49.644      1.22  (OK)
================================================================================
Executing test: super_light_async...
Reference binary: ./runtasks_ref_linux
Results for: super_light_async
                                        STUDENT   REFERENCE   PERF?
[Serial]                                43.896    40.416      1.09  (OK)
[Parallel + Always Spawn]               43.025    149.93      0.29  (OK)
[Parallel + Thread Pool + Spin]         43.679    29.589      1.48  (OK)
[Parallel + Thread Pool + Sleep]        28.933    24.183      1.20  (OK)
================================================================================
Executing test: ping_pong_equal...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_equal
                                        STUDENT   REFERENCE   PERF?
[Serial]                                704.422   648.376     1.09  (OK)
[Parallel + Always Spawn]               702.252   204.452     3.43  (NOT OK)
[Parallel + Thread Pool + Spin]         699.26    156.193     4.48  (NOT OK)
[Parallel + Thread Pool + Sleep]        191.514   151.617     1.26  (OK)
================================================================================
Executing test: ping_pong_equal_async...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_equal_async
                                        STUDENT   REFERENCE   PERF?
[Serial]                                700.791   647.809     1.08  (OK)
[Parallel + Always Spawn]               703.253   208.985     3.37  (NOT OK)
[Parallel + Thread Pool + Spin]         702.64    156.071     4.50  (NOT OK)
[Parallel + Thread Pool + Sleep]        183.948   139.78      1.32  (OK)
================================================================================
Executing test: ping_pong_unequal...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_unequal
                                        STUDENT   REFERENCE   PERF?
[Serial]                                1291.155  1214.399    1.06  (OK)
[Parallel + Always Spawn]               1297.076  265.625     4.88  (NOT OK)
[Parallel + Thread Pool + Spin]         1284.404  207.297     6.20  (NOT OK)
[Parallel + Thread Pool + Sleep]        262.049   201.473     1.30  (OK)
================================================================================
Executing test: ping_pong_unequal_async...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_unequal_async
                                        STUDENT   REFERENCE   PERF?
[Serial]                                1292.723  1214.691    1.06  (OK)
[Parallel + Always Spawn]               1293.555  263.932     4.90  (NOT OK)
[Parallel + Thread Pool + Spin]         1295.538  206.042     6.29  (NOT OK)
[Parallel + Thread Pool + Sleep]        258.012   197.771     1.30  (OK)
================================================================================
Executing test: recursive_fibonacci...
Reference binary: ./runtasks_ref_linux
Results for: recursive_fibonacci
                                        STUDENT   REFERENCE   PERF?
[Serial]                                672.702   1059.673    0.63  (OK)
[Parallel + Always Spawn]               676.334   144.753     4.67  (NOT OK)
[Parallel + Thread Pool + Spin]         671.824   160.962     4.17  (NOT OK)
[Parallel + Thread Pool + Sleep]        108.368   139.518     0.78  (OK)
================================================================================
Executing test: recursive_fibonacci_async...
Reference binary: ./runtasks_ref_linux
Results for: recursive_fibonacci_async
                                        STUDENT   REFERENCE   PERF?
[Serial]                                677.219   1065.529    0.64  (OK)
[Parallel + Always Spawn]               671.694   141.044     4.76  (NOT OK)
[Parallel + Thread Pool + Spin]         672.491   137.377     4.90  (NOT OK)
[Parallel + Thread Pool + Sleep]        101.067   134.396     0.75  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop
                                        STUDENT   REFERENCE   PERF?
[Serial]                                386.117   367.139     1.05  (OK)
[Parallel + Always Spawn]               390.633   763.636     0.51  (OK)
[Parallel + Thread Pool + Spin]         387.205   155.567     2.49  (NOT OK)
[Parallel + Thread Pool + Sleep]        335.568   260.16      1.29  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_async...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_async
                                        STUDENT   REFERENCE   PERF?
[Serial]                                379.027   357.445     1.06  (OK)
[Parallel + Always Spawn]               379.425   748.564     0.51  (OK)
[Parallel + Thread Pool + Spin]         381.661   129.059     2.96  (NOT OK)
[Parallel + Thread Pool + Sleep]        251.303   167.617     1.50  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fewer_tasks...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fewer_tasks
                                        STUDENT   REFERENCE   PERF?
[Serial]                                386.693   359.973     1.07  (OK)
[Parallel + Always Spawn]               385.614   767.266     0.50  (OK)
[Parallel + Thread Pool + Spin]         382.28    195.048     1.96  (NOT OK)
[Parallel + Thread Pool + Sleep]        361.556   261.403     1.38  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fewer_tasks_async...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fewer_tasks_async
                                        STUDENT   REFERENCE   PERF?
[Serial]                                383.238   362.11      1.06  (OK)
[Parallel + Always Spawn]               383.221   748.586     0.51  (OK)
[Parallel + Thread Pool + Spin]         383.377   60.354      6.35  (NOT OK)
[Parallel + Thread Pool + Sleep]        64.755    95.945      0.67  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fan_in...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fan_in
                                        STUDENT   REFERENCE   PERF?
[Serial]                                199.654   185.18      1.08  (OK)
[Parallel + Always Spawn]               199.644   111.129     1.80  (NOT OK)
[Parallel + Thread Pool + Spin]         200.94    46.147      4.35  (NOT OK)
[Parallel + Thread Pool + Sleep]        77.969    56.712      1.37  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fan_in_async...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fan_in_async
                                        STUDENT   REFERENCE   PERF?
[Serial]                                200.266   186.405     1.07  (OK)
[Parallel + Always Spawn]               196.858   107.224     1.84  (NOT OK)
[Parallel + Thread Pool + Spin]         196.916   34.597      5.69  (NOT OK)
[Parallel + Thread Pool + Sleep]        32.059    32.355      0.99  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_reduction_tree...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_reduction_tree
                                        STUDENT   REFERENCE   PERF?
[Serial]                                200.065   189.841     1.05  (OK)
[Parallel + Always Spawn]               198.557   55.519      3.58  (NOT OK)
[Parallel + Thread Pool + Spin]         195.579   36.797      5.32  (NOT OK)
[Parallel + Thread Pool + Sleep]        41.008    39.417      1.04  (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_reduction_tree_async...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_reduction_tree_async
                                        STUDENT   REFERENCE   PERF?
[Serial]                                196.123   183.502     1.07  (OK)
[Parallel + Always Spawn]               195.809   51.347      3.81  (NOT OK)
[Parallel + Thread Pool + Spin]         195.512   29.132      6.71  (NOT OK)
[Parallel + Thread Pool + Sleep]        34.974    29.707      1.18  (OK)
================================================================================
Executing test: spin_between_run_calls...
Reference binary: ./runtasks_ref_linux
Results for: spin_between_run_calls
                                        STUDENT   REFERENCE   PERF?
[Serial]                                238.154   376.977     0.63  (OK)
[Parallel + Always Spawn]               234.787   192.36      1.22  (OK)
[Parallel + Thread Pool + Spin]         235.452   236.406     1.00  (OK)
[Parallel + Thread Pool + Sleep]        121.11    192.589     0.63  (OK)
================================================================================
Executing test: spin_between_run_calls_async...
Reference binary: ./runtasks_ref_linux
Results for: spin_between_run_calls_async
                                        STUDENT   REFERENCE   PERF?
[Serial]                                242.261   376.192     0.64  (OK)
[Parallel + Always Spawn]               235.36    193.519     1.22  (OK)
[Parallel + Thread Pool + Spin]         235.4     229.247     1.03  (OK)
[Parallel + Thread Pool + Sleep]        121.462   194.465     0.62  (OK)
================================================================================
Executing test: mandelbrot_chunked...
Reference binary: ./runtasks_ref_linux
Results for: mandelbrot_chunked
                                        STUDENT   REFERENCE   PERF?
[Serial]                                296.609   275.69      1.08  (OK)
[Parallel + Always Spawn]               295.098   29.164      10.12  (NOT OK)
[Parallel + Thread Pool + Spin]         297.117   25.831      11.50  (NOT OK)
[Parallel + Thread Pool + Sleep]        25.4      24.446      1.04  (OK)
================================================================================
Executing test: mandelbrot_chunked_async...
Reference binary: ./runtasks_ref_linux
Results for: mandelbrot_chunked_async
                                        STUDENT   REFERENCE   PERF?
[Serial]                                297.946   274.831     1.08  (OK)
[Parallel + Always Spawn]               297.743   29.353      10.14  (NOT OK)
[Parallel + Thread Pool + Spin]         295.95    24.352      12.15  (NOT OK)
[Parallel + Thread Pool + Sleep]        27.117    25.444      1.07  (OK)
================================================================================
Overall performance results
[Serial]                                : All passed Perf
[Parallel + Always Spawn]               : Perf did not pass all tests
[Parallel + Thread Pool + Spin]         : Perf did not pass all tests
[Parallel + Thread Pool + Sleep]        : All passed Perf

OS:Windows11 wsl2 6.6.87.2-microsoft-standard-WSL2 Ubuntu 24.04.3 LTS

CPU: Intel Core i7 13620H 8 cores, 10 logic processors, AVX2

GPU:NVIDIA GeForce RTX 4060 Laptop

assignment3

cuda环境配置

NVIDIA官方为WSL2环境提供了专门的CUDA Toolkit安装包，该版本不包含Linux驱动程序，从而避免了与Windows驱动的冲突

在NVIDIA官网https://developer.nvidia.com/cuda-downloads选择对应的安装选项，按照生成的安装命令执行即可

例如本机WSL2配置命令如下

wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin
sudo mv cuda-wsl-ubuntu.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/13.1.1/local_installers/cuda-repo-wsl-ubuntu-13-1-local_13.1.1-1_amd64.deb
sudo dpkg -i cuda-repo-wsl-ubuntu-13-1-local_13.1.1-1_amd64.deb
sudo cp /var/cuda-repo-wsl-ubuntu-13-1-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-13-1

此后我们再打开~/.bashrc配置环境变量，在最后加上以下内容

export CUDA_HOME=/usr/local/cuda-13.1
export PATH=$CUDA_HOME/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

source ~/.bashrc后，使用nvcc --version验证结果如下

saxpy

要求我们补全saxpy.cu的代码，并且统计运行的总时间和kernel内计算的时间

需要注意的是，cudaMalloc，cudaFree，cudaMemcpy都是与主线程同步执行，而kernel内的计算是与主线程异步的，统计计算时间之前需要使用cudaDeviceSynchronize()

void saxpyCuda(int N, float alpha, float* xarray, float* yarray, float* resultarray) {

    // must read both input arrays (xarray and yarray) and write to
    // output array (resultarray)
    int totalBytes = sizeof(float) * 3 * N;

    // compute number of blocks and threads per block.  In this
    // application we've hardcoded thread blocks to contain 512 CUDA
    // threads.
    const int threadsPerBlock = 512;

    // Notice the round up here.  The code needs to compute the number
    // of threads blocks needed such that there is one thread per
    // element of the arrays.  This code is written to work for values
    // of N that are not multiples of threadPerBlock.
    const int blocks = (N + threadsPerBlock - 1) / threadsPerBlock;

    // These are pointers that will be pointers to memory allocated
    // *one the GPU*.  You should allocate these pointers via
    // cudaMalloc.  You can access the resulting buffers from CUDA
    // device kernel code (see the kernel function saxpy_kernel()
    // above) but you cannot access the contents these buffers from
    // this thread. CPU threads cannot issue loads and stores from GPU
    // memory!
    float* device_x = nullptr;
    float* device_y = nullptr;
    float* device_result = nullptr;
    
    //
    // CS149 TODO: allocate device memory buffers on the GPU using cudaMalloc.
    //
    // We highly recommend taking a look at NVIDIA's
    // tutorial, which clearly walks you through the few lines of code
    // you need to write for this part of the assignment:
    //
    // https://devblogs.nvidia.com/easy-introduction-cuda-c-and-c/
    //
    cudaMalloc(&device_x, totalBytes / 3);
    cudaMalloc(&device_y, totalBytes / 3);
    cudaMalloc(&device_result, totalBytes / 3);
    // start timing after allocation of device memory
    double startTime = CycleTimer::currentSeconds();

    //
    // CS149 TODO: copy input arrays to the GPU using cudaMemcpy
    //

    cudaMemcpy(device_x, xarray, totalBytes / 3, cudaMemcpyHostToDevice);
    cudaMemcpy(device_y, yarray, totalBytes / 3, cudaMemcpyHostToDevice);
   
    // run CUDA kernel. (notice the <<< >>> brackets indicating a CUDA
    // kernel launch) Execution on the GPU occurs here.
    double kernel_time = CycleTimer::currentSeconds();
    saxpy_kernel<<<blocks, threadsPerBlock>>>(N, alpha, device_x, device_y, device_result);
    cudaDeviceSynchronize();
    kernel_time = CycleTimer::currentSeconds() - kernel_time;
    //
    // CS149 TODO: copy result from GPU back to CPU using cudaMemcpy
    //

    cudaMemcpy(resultarray, device_result, totalBytes / 3, cudaMemcpyDeviceToHost);
    
    // end timing after result has been copied back into host memory
    double endTime = CycleTimer::currentSeconds();

    cudaError_t errCode = cudaPeekAtLastError();
    if (errCode != cudaSuccess) {
        fprintf(stderr, "WARNING: A CUDA error occured: code=%d, %s\n",
		errCode, cudaGetErrorString(errCode));
    }

    double overallDuration = endTime - startTime;
    printf("Effective BW of kernel: %.3f ms\t\t[%.3f GB/s]\n", 1000.f * kernel_time, GBPerSec(totalBytes, kernel_time));
    printf("Effective BW by CUDA saxpy: %.3f ms\t\t[%.3f GB/s]\n", 1000.f * overallDuration, GBPerSec(totalBytes, overallDuration));

    //
    // CS149 TODO: free memory buffers on the GPU using cudaFree
    //
    cudaFree(device_x); cudaFree(device_y); cudaFree(device_result);
}

运行结果如下

Found 1 CUDA devices
Device 0: NVIDIA GeForce RTX 4060 Laptop GPU
   SMs:        24
   Global mem: 8188 MB
   CUDA Cap:   8.9
---------------------------------------------------------
Running 3 timing tests:
Effective BW of kernel: 13.045 ms               [85.673 GB/s]
Effective BW by CUDA saxpy: 153.652 ms          [7.273 GB/s]
Effective BW of kernel: 5.262 ms                [212.398 GB/s]
Effective BW by CUDA saxpy: 135.543 ms          [8.245 GB/s]
Effective BW of kernel: 5.248 ms                [212.972 GB/s]
Effective BW by CUDA saxpy: 136.620 ms          [8.180 GB/s]

对比同样数据规模的ISPC优化

[saxpy serial]:         [52.145] ms     [28.577] GB/s   [3.835] GFLOPS
[saxpy ispc]:           [51.940] ms     [28.689] GB/s   [3.851] GFLOPS
[saxpy task ispc]:      [31.122] ms     [47.879] GB/s   [6.426] GFLOPS

发现在计算方面，cuda加速比CPU快得多，但是cudaMemcpy内存通信开销极大，甚至慢于串行执行；而在GPU内部带宽接近于RTX4060的理论带宽 256.0 GB/s。这表明device和host的通信才是性能的瓶颈

scan

注意此题测试参考程序依赖于cuda 12的运行时库，而我本地是cuda 13，需要通过以下命令安装cuda 12，并且修改.bashrc

wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin
sudo mv cuda-wsl-ubuntu.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/12.8.1/local_installers/cuda-repo-wsl-ubuntu-12-8-local_12.8.1-1_amd64.deb
sudo dpkg -i cuda-repo-wsl-ubuntu-12-8-local_12.8.1-1_amd64.deb
sudo cp /var/cuda-repo-wsl-ubuntu-12-8-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt update

可以使用以下命令进行版本切换：sudo update-alternatives --config cuda

要求我们使用Blelloch算法实现并行前缀和，并调用该函数无锁地实现find_repeats用来并行找出所有满足input[i]==input[i+1]的i构成的序列

首先是并行前缀和，代码如下

__global__ void Kernel_up_sweep(int *arrary, int threads, int stride) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    if (idx < threads) {
        int id1 = idx * stride + (stride >> 1), id2 = (idx + 1) * stride;
        id1--; id2--;  
        arrary[id2] = arrary[id1] + arrary[id2];
    }
}

__global__ void Kernel_down_sweep(int *arrary, int threads, int stride) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    if (idx < threads) {
        int id1 = idx * stride + (stride >> 1), id2 = (idx + 1) * stride;
        id1--; id2--;
        int x = arrary[id1], y = arrary[id2];
        arrary[id1] = y; arrary[id2] = x + y;
    }
}

void exclusive_scan(int* input, int N, int* result)
{

    // CS149 TODO:
    //
    // Implement your exclusive scan implementation here.  Keep in
    // mind that although the arguments to this function are device
    // allocated arrays, this is a function that is running in a thread
    // on the CPU.  Your implementation will need to make multiple calls
    // to CUDA kernel functions (that you must write) to implement the
    // scan.

    int n = nextPow2(N);
    for (int stride = 2; stride <= n / 2; stride <<= 1) {
        int threads = n / stride, blocks = (threads - 1 + THREADS_PER_BLOCK) / THREADS_PER_BLOCK;
        Kernel_up_sweep<<<blocks, THREADS_PER_BLOCK>>>(result, threads, stride);
        cudaDeviceSynchronize();
    }
    cudaMemset(result + (n - 1), 0, sizeof(int));
    for (int stride = n; stride >= 2; stride >>= 1) {
        int threads = n / stride, blocks = (threads - 1 + THREADS_PER_BLOCK) / THREADS_PER_BLOCK;
        Kernel_down_sweep<<<blocks, THREADS_PER_BLOCK>>>(result, threads, stride);
        cudaDeviceSynchronize();
    }
}

测试结果如下

Scan Score Table:
-------------------------
-------------------------------------------------------------------------
| Element Count   | Ref Time        | Student Time    | Score           |
-------------------------------------------------------------------------
| 1000000         | 0.968           | 0.999           | 1.25            |
| 10000000        | 10.075          | 8.529           | 1.25            |
| 20000000        | 20.351          | 13.911          | 1.25            |
| 40000000        | 38.031          | 26.655          | 1.25            |
-------------------------------------------------------------------------
|                                   | Total score:    | 5.0/5.0         |
-------------------------------------------------------------------------

对于find_repeats的实现，我们可以先并行执行得到对于每个i是否满足input[i]==input[i+1]，这构成了一个布尔序列，对于这个布尔序列做一次并行前缀和，得到此前重复的数的数量，也就是当前数如果重复应该被放入结果序列的位置，按照这个做一次scatter即可

__global__ void Kernel_if_repeat(int *arrary, int n, int *output) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    if (idx + 1 < n) {
        output[idx] = (arrary[idx] == arrary[idx + 1]);
    }
}

__global__ void Kernel_find_repeats(int *flag, int *index, int n, int *output) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    if (idx + 1 < n && flag[idx]) {
        output[index[idx]] = idx;
    }
}

int find_repeats(int* device_input, int length, int* device_output) {

    // CS149 TODO:
    //
    // Implement this function. You will probably want to
    // make use of one or more calls to exclusive_scan(), as well as
    // additional CUDA kernel launches.
    //    
    // Note: As in the scan code, the calling code ensures that
    // allocated arrays are a power of 2 in size, so you can use your
    // exclusive_scan function with them. However, your implementation
    // must ensure that the results of find_repeats are correct given
    // the actual array length.
    int n = nextPow2(length);
    int *flag = nullptr, *sum = nullptr;
    cudaMalloc(&flag, sizeof(int) * n);
    cudaMalloc(&sum, sizeof(int) * n);
    int blocks = (n + THREADS_PER_BLOCK - 1) / THREADS_PER_BLOCK;
    Kernel_if_repeat <<<blocks, THREADS_PER_BLOCK>>> (device_input, n, flag);
    cudaDeviceSynchronize();
    cudaMemcpy(sum, flag, sizeof(int) * n, cudaMemcpyDeviceToDevice);
    exclusive_scan(sum, n, sum);
    Kernel_find_repeats <<<blocks, THREADS_PER_BLOCK>>> (flag, sum, n, device_output);
    cudaDeviceSynchronize();
    int cnt;
    cudaMemcpy(&cnt, sum + length - 1, sizeof(int), cudaMemcpyDeviceToHost);
    cudaFree(flag); cudaFree(sum);
    return cnt; 
}

测试结果如下

Find_repeats Score Table:
-------------------------
-------------------------------------------------------------------------
| Element Count   | Ref Time        | Student Time    | Score           |
-------------------------------------------------------------------------
| 1000000         | 1.887           | 2.02            | 1.25            |
| 10000000        | 16.067          | 14.997          | 1.25            |
| 20000000        | 28.853          | 26.017          | 1.25            |
| 40000000        | 56.414          | 50.418          | 1.25            |
-------------------------------------------------------------------------
|                                   | Total score:    | 5.0/5.0         |
-------------------------------------------------------------------------

render

make之前需要配置相关的环境

sudo apt update
sudo apt install freeglut3-dev

提供了一个简单渲染器的顺序实现和cuda实现，其中cuda实现存在错误

在安装feh之后，可以通过以下命令运行顺序实现查看渲染结果./render -r cpuref snow -i

其中渲染算法维护了多个圆的信息，每个圆有其圆心位置，半径，速度，颜色，透明度(一个$[0,1]$之间的实数)，算法流程如下

对于每一帧：
	清空图像
	对于每一个圆：
		更新其位置和速度
	对于每一个圆：
		计算出能包含该圆的正方形
		对于这个正方形内的每一个坐标：
			计算这个坐标的中心
			如果这个中心在圆内：
				计算这个圆在此处的颜色
				使用这个颜色的贡献更新坐标像素上

对于像素的贡献算法如下：

   result_r = C_alpha * C_r + (1.0 - C_alpha) * P_r
   result_g = C_alpha * C_g + (1.0 - C_alpha) * P_g
   result_b = C_alpha * C_b + (1.0 - C_alpha) * P_b

其中result_r/g/b表示计算贡献后的像素rgb值，C_alpha表示圆的透明度，P_r/g/b表示此前像素的rgb值

注意该贡献算法不满足结合律，即计算出像素的rgb值与圆贡献的顺序相关，此渲染器要求贡献顺序为圆输入顺序

提示告诉我们，cuda版本的render没有满足贡献计算的原子性以及贡献的顺序，需要我们对其进行修改

初始代码贡献计算部分如下

__global__ void kernelRenderCircles() {

    int index = blockIdx.x * blockDim.x + threadIdx.x;

    if (index >= cuConstRendererParams.numCircles)
        return;

    int index3 = 3 * index;

    // read position and radius
    float3 p = *(float3*)(&cuConstRendererParams.position[index3]);
    float  rad = cuConstRendererParams.radius[index];

    // compute the bounding box of the circle. The bound is in integer
    // screen coordinates, so it's clamped to the edges of the screen.
    short imageWidth = cuConstRendererParams.imageWidth;
    short imageHeight = cuConstRendererParams.imageHeight;
    short minX = static_cast<short>(imageWidth * (p.x - rad));
    short maxX = static_cast<short>(imageWidth * (p.x + rad)) + 1;
    short minY = static_cast<short>(imageHeight * (p.y - rad));
    short maxY = static_cast<short>(imageHeight * (p.y + rad)) + 1;

    // a bunch of clamps.  Is there a CUDA built-in for this?
    short screenMinX = (minX > 0) ? ((minX < imageWidth) ? minX : imageWidth) : 0;
    short screenMaxX = (maxX > 0) ? ((maxX < imageWidth) ? maxX : imageWidth) : 0;
    short screenMinY = (minY > 0) ? ((minY < imageHeight) ? minY : imageHeight) : 0;
    short screenMaxY = (maxY > 0) ? ((maxY < imageHeight) ? maxY : imageHeight) : 0;

    float invWidth = 1.f / imageWidth;
    float invHeight = 1.f / imageHeight;

    // for all pixels in the bonding box
    for (int pixelY=screenMinY; pixelY<screenMaxY; pixelY++) {
        float4* imgPtr = (float4*)(&cuConstRendererParams.imageData[4 * (pixelY * imageWidth + screenMinX)]);
        for (int pixelX=screenMinX; pixelX<screenMaxX; pixelX++) {
            float2 pixelCenterNorm = make_float2(invWidth * (static_cast<float>(pixelX) + 0.5f),
                                                 invHeight * (static_cast<float>(pixelY) + 0.5f));
            shadePixel(index, pixelCenterNorm, p, imgPtr);
            imgPtr++;
        }
    }
}

这是对于每一个圆并行计算对其中像素的贡献，但是由于乱序，会导致结果出错

在串行执行算法中，对每个圆计算和对每个像素计算都具有并行性，但是由于不满足结合律，我们只能考虑后者

一个trivial的做法是对于每一个像素运行一个cuda线程，依次遍历每一个圆尝试计算贡献

__global__ void kernelRenderPixels() {
    int x = blockIdx.x * blockDim.x + threadIdx.x;
    int y = blockIdx.y * blockDim.y + threadIdx.y;
    int width = cuConstRendererParams.imageWidth, height = cuConstRendererParams.imageHeight;
    if (x >= width || y >= height) return;
    float invwidth = 1.f / width, invheight = 1.f / height; 
    float2 pixelCenterNorm = make_float2(invwidth * (static_cast<float>(x) + 0.5f), invheight * (static_cast<float>(y) + 0.5f));
    float4 *imgPtr = (float4*)(&cuConstRendererParams.imageData[4 * (y * width + x)]);
    for (int i = 0; i < cuConstRendererParams.numCircles; i++) {
        float3 p = *(float3*)(&cuConstRendererParams.position[3 * i]);
        shadePixel(i, pixelCenterNorm, p, imgPtr);
    }
}

测试结果如下

Score table:
------------
--------------------------------------------------------------------------
| Scene Name      | Ref Time (T_ref) | Your Time (T)   | Score           |
--------------------------------------------------------------------------
| rgb             | 0.3232           | 0.2669          | 9               |
| rand10k         | 2.8221           | 39.2085         | 2               |
| rand100k        | 23.3191          | 382.3064        | 2               |
| pattern         | 0.6382           | 5.5301          | 3               |
| snowsingle      | 15.0153          | 343.2084        | 2               |
| biglittle       | 13.4723          | 43.2001         | 5               |
| rand1M          | 154.3743         | 3913.552        | 2               |
| micro2M         | 294.7338         | 7892.6395       | 2               |
--------------------------------------------------------------------------
|                                    | Total score:    | 27/72           |
--------------------------------------------------------------------------

实际运行效率比CPU串行执行还低（），这是因为更新一个像素需要扫描所有的圆，而实际上许多像素根本不会处在大多数圆内

为了减少冗余计算，可以考虑将整个坐标系分割成多个矩形，若这个矩形和一个圆不相交，那么该矩形中所有像素一定都不在这个圆内

已经为我们提供了circleInBox的接口，直接调用即可

#define BLOCKX 16
#define BLOCKY 16
#define THREADX 16
#define THREADY 16

__global__ void kernelRenderPixels() {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    int idy = blockIdx.y * blockDim.y + threadIdx.y;
    int width = cuConstRendererParams.imageWidth, height = cuConstRendererParams.imageHeight;
    float invwidth = 1.f / width, invheight = 1.f / height;
    int X0 = idx * THREADX, X1 = X0 + THREADX;
    int Y0 = idy * THREADY, Y1 = Y0 + THREADY; 
    if (X0 >= width || Y0 >= height) return;
    float normX0 = X0 * invwidth, normX1 = X1 * invwidth;
    float normY0 = Y0 * invheight, normY1 = Y1 * invheight;
    int num = cuConstRendererParams.numCircles;
    for (int i = 0; i < num; i++) {
        float cirx = cuConstRendererParams.position[3 * i], ciry = cuConstRendererParams.position[3 * i + 1];
        float cirr = cuConstRendererParams.radius[i];
        if (circleInBox(cirx, ciry, cirr, normX0, normX1, normY1, normY0)) {
            float3 p = *(float3*)(&cuConstRendererParams.position[3 * i]);
            for (int j = Y0; j < Y1; j++) {
                float _y = static_cast <float> (j) + 0.5f; 
                float4* imgPtr = (float4*)(&cuConstRendererParams.imageData[4 * (j * width + X0)]);
                for (int k = X0; k < X1; k++) {
                    float _x = static_cast <float> (k) + 0.5f;
                    shadePixel(i, make_float2(invwidth * _x, invheight * _y), p, imgPtr);
                    ++imgPtr;
                }
            }
        }
    }
}

void
CudaRenderer::render() {

    // 256 threads per block is a healthy number
    dim3 blockDim(THREADX, THREADY);
    dim3 gridDim((image->width + blockDim.x - 1) / blockDim.x, (image->height + blockDim.y - 1) / blockDim.y);

    kernelRenderPixels<<<gridDim, blockDim>>>();
    cudaDeviceSynchronize();
}

运行结果如下，效率有了较大提升

Score table:
------------
--------------------------------------------------------------------------
| Scene Name      | Ref Time (T_ref) | Your Time (T)   | Score           |
--------------------------------------------------------------------------
| rgb             | 0.2807           | 0.8516          | 5               |
| rand10k         | 2.729            | 29.2422         | 2               |
| rand100k        | 23.1492          | 234.5919        | 2               |
| pattern         | 0.6532           | 1.1787          | 6               |
| snowsingle      | 14.8701          | 30.8657         | 6               |
| biglittle       | 13.9142          | 416.6634        | 2               |
| rand1M          | 154.5485         | 523.2159        | 5               |
| micro2M         | 296.6468         | 496.183         | 7               |
--------------------------------------------------------------------------
|                                    | Total score:    | 35/72           |
--------------------------------------------------------------------------

但是我们发现这段代码是对于每个16 * 16的像素块，都串行地与所有圆判断是否相交，这一部分仍然可以并行化

于是，我们考虑仍然使用一个线程处理每一个像素，但是同时，一个线程块内的线程需要并行地计算这个线程块构成的像素矩阵与每个圆的相交情况，然后计算相交的圆对自己这个线程对应的像素的贡献

在实现上来说，我们采用__shared__共享内存来进行线程块内通信，线程块内16*16=256个线程每个每次判断像素矩阵是否与一个圆相交，这样得到了一个布尔数组，采用类似第二部分的实现就可以得到相交的圆的数组，然后每个线程再并行的对自己负责的像素依次尝试用这些圆更新即可。注意我们在计算相交的布尔数组处采用了屏障同步，这就使得后256个圆不会先于前256个圆进行计算，进而保证了正确性

#define BLOCKX 16
#define BLOCKY 16
#define BLOCKSIZE 256
#define SCAN_BLOCK_DIM   BLOCKSIZE  
#include "exclusiveScan.cu_inl"

__global__ void kernelRenderPixels() {
    __shared__ uint isinside[BLOCKSIZE], insidesum[BLOCKSIZE], tmp[BLOCKSIZE << 1], cir[BLOCKSIZE];
    int width = cuConstRendererParams.imageWidth, height = cuConstRendererParams.imageHeight;
    float invwidth = 1.0f / width, invheight = 1.0f / height;
    int X0 = blockIdx.x * BLOCKX, X1 = min(X0 + BLOCKX, width);
    int Y0 = blockIdx.y * BLOCKY, Y1 = min(Y0 + BLOCKY, height);
    float normX0 = X0 * invwidth, normX1 = X1 * invwidth;
    float normY0 = Y0 * invheight, normY1 = Y1 * invheight;
    int threadid = threadIdx.y * BLOCKX + threadIdx.x;
    int num = cuConstRendererParams.numCircles; 
    int pixelx = X0 + threadIdx.x;
    int pixely = Y0 + threadIdx.y;
    float2 pixel = make_float2(invwidth * (static_cast<float>(pixelx) + 0.5f), invheight * (static_cast <float>(pixely) + 0.5f));
    float4 *imgPtr = (float4*)(&cuConstRendererParams.imageData[4 * (pixely * width + pixelx)]);
    for (int _i = 0; _i < num; _i += BLOCKSIZE) {
        int i = _i + threadid;
        if (i < num) {
            float cirx = cuConstRendererParams.position[3 * i], ciry = cuConstRendererParams.position[3 * i + 1];
            float cirr = cuConstRendererParams.radius[i];
            isinside[threadid] = circleInBox(cirx, ciry, cirr, normX0, normX1, normY1, normY0);            
        }
        else isinside[threadid] = 0;

        __syncthreads();
        sharedMemExclusiveScan(threadid, isinside, insidesum, tmp, BLOCKSIZE); 
        if (isinside[threadid]) {
            cir[insidesum[threadid]] = i;
        }
        __syncthreads();
        if (pixelx < width && pixely < height) {
            int cirnum = insidesum[BLOCKSIZE - 1] + isinside[BLOCKSIZE - 1];
            for (int j = 0; j < cirnum; j++) {
                int ciridx = cir[j];
                float3 p = *(float3*)(&cuConstRendererParams.position[ciridx * 3]);
                shadePixel(ciridx, pixel, p, imgPtr);
            }               
        }
    }
}

void
CudaRenderer::render() {

    // 256 threads per block is a healthy number
    dim3 blockDim(BLOCKX, BLOCKY);
    dim3 gridDim((image->width + blockDim.x - 1) / blockDim.x, (image->height + blockDim.y - 1) / blockDim.y);

    kernelRenderPixels<<<gridDim, blockDim>>>();
    cudaDeviceSynchronize();
}

测试结果如下

Score table:
------------
--------------------------------------------------------------------------
| Scene Name      | Ref Time (T_ref) | Your Time (T)   | Score           |
--------------------------------------------------------------------------
| rgb             | 0.4447           | 0.4018          | 9               |
| rand10k         | 3.3763           | 3.7078          | 9               |
| rand100k        | 28.7109          | 32.373          | 9               |
| pattern         | 0.5684           | 0.5763          | 9               |
| snowsingle      | 20.157           | 18.984          | 9               |
| biglittle       | 13.8375          | 32.426          | 5               |
| rand1M          | 153.9384         | 153.1018        | 9               |
| micro2M         | 295.5285         | 288.3962        | 9               |
--------------------------------------------------------------------------
|                                    | Total score:    | 68/72           |

三大核心理念

1. 多核执行：发掘程序的并行性，将可以并行的部分交给不同的处理器核执行
2. SIMD执行：通过向量化，让一个处理器核一条指令对一个向量执行相同的操作
3. 硬件多线程：在一个处理器核中维护多个上下文，当一个线程停顿时(如cache miss)，进行上下文切换执行其它线程，提高利用率

并行化程序的过程

Decomposition

发掘程序的并行性，将问题分解为可并行计算的多个小部分

Amdahl's law：设 $S$为程序中可以并行执行的部分，运行在$p$个处理器上，那么有加速比$speedup \leq \frac{1}{(1-S)+\frac{S}{p}}$

由此可见，设计的程序的可并行性是加速的决定性因素

ISPC 基本语法

Assignment

并行计算完成的时间，取决于最慢的那个线程

所以每个线程(或每个处理器核)执行的任务量越平均(即负载越平均)，理论上花费的时间就越短

可以将任务按照粒度依次分配给每个进程，粒度越小进程的负载越平均，但是进程间通信的开销也会变大

Cilk 语法

Orchestration

通信是广义的，节点间存在通信，线程间存在通信，线程对内存的访问也是一种通信

共享地址空间系统(多线程共享内存)：所有线程对同一个地址空间进行读写，缓存一致性由硬件自动维护，通过锁和屏障完成同步

消息传递系统(分布式系统)：每个处理核或节点有独立的内存地址空间，需要通过显式发送和接受消息来通信

以下以消息传递系统为例，节点间的通信分为同步通信和异步通信

同步通信采用了阻塞发送/接收的方式达到同步，即一直阻塞直到消息发送/接收成功，编程简单，但是并发度低

异步通信采用非阻塞发送/接收，发送时将消息复制并暂存在缓冲区内，需要接收时再取走消息，高并发，但是编程复杂

算数强度：计算次数与通信次数的比例

按照通信的类型，可以分为固有通信和人为通信，前者由算法固有的性质决定，后者由机器工作方式决定

通过改进算法(如使用分块技术)可以减少固有通信

mapping

并行任务被映射到对应的硬件上，可以由系统/程序员或者两者都有进行指定

GPU与CUDA

GPU的作用：给定一个场景的数学描述，经过模拟生成这个场景的图片，例如对每个像素计算一些输入，然后在每个像素上独立运行来计算一些颜色

在NVIDIA推出CUDA之前，操纵GPU进行科学计算需要将数据包装成图形渲染问题，这是相等低效且复杂的

GPU由很多个小的计算核心组成，所以可以很好地处理逻辑简单的并行计算

SM Processing Block组成如下

多个SMP组成了一个Stream Multi-processor(SM)，一个SM内的SMP共享内存

在CPU上，由编译器在软件层面实现SIMD；GPU上则是在硬件层面，每个SMP对于它的一个wrap(多个连续的PC相同的Cuda进程)执行隐式SIMD

CUDA 语法

序列数据并行

map

将某个函数作用于序列，得到一个等长的序列

可并行化的map：要求函数的结果相互之间没有依赖

fold(reduce)

从左到右对序列进行二元操作，得到一个标量

可并行化的fold：运算与合并顺序无关，满足交换律

scan

对序列每个进行前缀fold，得到的所有标量组合起来，形成一个序列

inclusive scan:对$[0,i]$做scan exclusive scan:对$[0,i-1]$做scan

求前缀和就是一种scan，下面讨论前缀和的并行性，以下假设序列长度为n，处理器数为p

分段并行前缀和

将原序列连续尽量均匀分为p块，每块串行计算内部前缀和，再串行地对于每一块，将该块最后一个前缀和并行地加到下一块的每个前缀和上

时间复杂度为$O(\frac{n}{p}+p)$，显然有$p = \sqrt{n}$的时候最优，复杂度为$O(\sqrt{n})$，但是访存连续，有较好的缓存友好性

实际上本质是分块算法

Blelloch 前缀和算法

Blelloch算法要求序列大小是2的次幂，不满足则需要进行填充

该算法分为两部分，Up-Sweep向上扫描和Down-Sweep向下扫描

向上扫描部分类似于fenwick tree的建树(沟槽的数据结构还在追我)，对于1-index，c[i]保存$[i-lowbit(i)+1, i]$的和

向下扫描部分则是每层分成若干个2的幂次的子区间，这些子区间的最后一个数第一次被赋值为非0的数时，都保存着$[0,该子区间左端点)$的和，向下递归的时候进行传播

先假设处理器足够多，每一层都能$O(1)$处理，时间复杂度与递归层数同阶为$O(\log_2n)$

总工作量为$O((\frac{n}{2}+\frac{n}{4}+...+2)\times2)=O(n)$，解得处理器数量$P \leq \frac{O(n)}{O(\log_2n)}=O(\frac{n}{log_2n})$，即当处理器数量至少为$O(\frac{n}{log_2n})$时可以达到最优复杂度，但是访存不连续，对缓存不友好

segmented scan

我们可以用start-flag法来表示一个序列的序列，具体来说，用第一个序列来按顺序存储所有序列的所有元素，用第二个布尔序列来表示第一个序列对应位置的元素是否是一个新序列的第一个元素

序列反而序列同样可以进行scan操作，在Blelloch算法中根据flag位决定是否进行传播即可

基于此，我们可以设计并行的稀疏矩阵乘法

gather/scatter

gather：output[i]=input[index[i]]

scatter：output[index[i]]=input[i]

注意scatter可以通过sort+map+gather得到

其他序列操作

分布式系统与并行计算

现代分布式系统的结构如下，通信的瓶颈一般在于网络带宽

相同机架内的节点一般通信较快，而不同机架内的节点则比较缓慢

分布式文件系统 (DFS)

对于一份数据，将其按照一定大小(如64-256MB)分割成多个小块，每一块保存多个副本，放入不同的节点中

系统中有一个主节点保存了元数据(所有数据的索引)

在对文件进行查询时，通过主节点中的信息访问任意一个存储了该文件的节点即可

在对文件进行修改时，通过主节点中的信息修改所有存储了该文件的节点

好处在于多个副本可以被并行地查询提高效率，同时也降低了故障率(多个节点同时出错概率极小)

MapReduce编程模型

考虑以下串行代码　

int key[], value[], result[];

for (int i = 0; i < n; i++) {
    value[i] = map(key[i]);
}
for (int i = 0; i < n; i++) {
    result[key[i]] = reduce(result[key[i]], value[i]);
}

即对于所有key相同的元素，将其map操作映射的值进行reduce

在考虑如何在分布式系统上并行地实现该代码，以下以wordcount为例，此时map映射结果恒为1，reduce操作为加法

对于分布式的每个节点，尽量在本地进行map操作得到对应的value，如果负载极度不均匀则需要先调度。此后进行屏障同步

按照一种保证同样的key值会被分配到相同reduce节点的分配方式(如key哈希值取模)，将所有的<key, value>传送到对应的reduce节点上进行reduce操作，得到结果后再写回分布式系统

spark

咕咕嘎嘎

DNN的并行优化

等后面学深度学习再来看，咕咕嘎嘎

一致性

缓存一致性

为了保持高带宽，一级缓存和二级缓存都由处理器核私有

当多个线程并行执行的时候，如果按照串行执行的缓存管理方式，内存的数据副本存放在处理器私有缓存中，当一个处理器核写数据时，如果不更新该数据在其他缓存中的副本，就会导致相同数据值不同，也就是缓存不一致

我们的目的是达到缓存一致性，即对于内存中的每一个地址，其并行访问的结果与不同线程按照时间排序后的顺序访问的结果相同

一种实现方式是采用嗅探法，以下以MSI缓存一致性协议为例

处理器核之间由一条总线连接起来，每时每刻处理器核都在监听总线，也可以向总线广播信息使得每个处理器核都接收到信息

对于缓存中的每一行，其脏位都存储了信息，表示这一行处于以下三种状态中的哪一种：

M(modified)：内存中该行对应的数据未被更新，更新后的数据仅存在于这一行中

S(shared)：内存中该行对应的数据已经被更新，并且存在于包含这一行的多行中

I(invalid)：这一行的内容已经失效

下面这张图表明了MSI协议下行状态的转移

其中转移条件A/B表示嗅探到了与当前处理器核中一个缓存行相关的广播A，接下来会进行措施B，并将这个缓存行的状态改为箭头指向的状态

例如当处于M状态时，嗅探到发生了BusRdX总线读独占，说明是其他处理器核尝试更新该数据并独占，那么就将当前缓存行的数据写回内存，并转移到I状态，其他处理器核再根据内存的信息进行更新

对外可见性的传播可能在不同核、不同 cache line 上表现出不同的生效时机，所以当前的缓存状态不一定被及时更新，进而可能导致缓存信息不同

基于MSI协议，还有MESI，MOESI等协议通过加入更多状态，提高了性能

伪共享

当我们创造了num_thread个int变量，每个线程访问其对应的变量，那么多个线程对不同变量的访问发生在同一缓存行内，导致一些缓存行被频繁地无效化，严重影响性能

解决方法是采用手动填充到缓存行大小，或者采用alignas内存强制对齐到缓存行大小

内存一致性

多线程系统中，不同核心观测到的顺序可能与期望的顺序不同，如编译器为了优化性能，执行指令的顺序可能会重排后乱序执行，导致多线程下因对内存访问顺序改变而出错

后面是真听不懂了

锁与原子变量

死锁：多个线程互相等待对方释放资源后才能执行，导致所有线程都无法继续执行

活锁：线程没有阻塞，但是重试运行一直失败，一直在运行但是没有进展

饥饿：一些线程取得了进展，但是其他线程因为资源被取得进程的线程占用而暂时无法取得进展

锁的实现

锁的本质是内存中一个用来记录当前线程是否应该继续进行的变量

考虑以下在硬件上被实现为原子操作的test_and_set指令

int test_and_set(int *addr) {
    int x = *addr;
    *addr = 1;
    return x;
}

根据该指令，我们可以设计出$TAS$锁

void Lock(int *lock) {
    while (test_and_set(lock));
}

void Unlock(int *lock) {
    *lock = 0;
}

在一个线程持有锁的时候，其它线程会反复地对锁尝试读写直到解锁，为保持缓存一致性，这带来了严重的效率问题

考虑以下改进TTAS锁

void Lock(int *lock) {
	while (1) {
        while(*lock);
        if (test_and_set(lock) == 0) return;
	}   
}

这样，每次不持有锁的线程只会对锁进行读，减少了缓存不命中。直到解锁的时候，所有其它线程才会对锁进行一次读写尝试获得锁

注意以上两者这是非公平锁，即获得锁的顺序取决于操作系统的调度，可能导致线程饥饿

另一种思想被称为ticket lock，思想类似于生活中的拿号排队

struct ticket_lock {
	int ticket;
    int serving;
};

void Lock(ticket_lock *l) {
	int t = atomic_increment(&l->ticket);
    while (l->serving < t);
}

void Unlock(ticket *l) {
    l->serving++;//注意同一时刻最多执行一次Unlock,无需使用原子操作
}

ticket lock被称为公平锁，它是FIFO的，避免了线程饥饿

原子操作

cuda内置了一系列的原子操作，以atomicCAS为例，其原子执行的逻辑如下

void atomicCAS(int *addr, int compare, int val) {
    int old = *addr;
    *addr = (old == compare)? val : old;
    return old;
}

基于该函数，我们能实现许多原子操作，例如atomicmin

void atomicmin(int *addr, int x) {
    int old, now;
    do {
		old = *addr, now = min(old, x);
    } while (atomicCAS(addr, old, now) != old);
}

C++的atomic类型在实现上，对于小类型采用原子操作，大类型采用锁实现

assignments

环境：

OS:Windows11 wsl2 6.6.87.2-microsoft-standard-WSL2 Ubuntu 24.04.3 LTS

CPU: Intel Core i7 13620H 8 cores, 10 logic processors, AVX2

GPU:NVIDIA GeForce RTX 4060 Laptop

assignment1

assignment2

assignment3

Part A Y86-64程序

规则：给定你一段C语言代码，需要使用$Y86-64$汇编代码写出与其函数上等价的代码

由于$Y86-64$功能有限，你需要将测试的输入也写在代码中

目录下使用 ./yas test.ys 编译 ./yis test.yo得到运行的结果

要求对于一个链表进行元素求和，其中C代码如下

/* $begin examples */
/* linked list element */
typedef struct ELE {
    long val;
    struct ELE *next;
} *list_ptr;

/* sum_list - Sum the elements of a linked list */
long sum_list(list_ptr ls)
{
    long val = 0;
    while (ls) {
	val += ls->val;
	ls = ls->next;
    }
    return val;
}

/* rsum_list - Recursive version of sum_list */
long rsum_list(list_ptr ls)
{
    if (!ls)
	return 0;
    else {
	long val = ls->val;
	long rest = rsum_list(ls->next);
	return val + rest;
    }
}

比较简单，直接实现即可

##################################################################
#initialization

.pos 0
irmovq stack, %rsp
call main
halt


#sample linked list

.align 8
ele1:
    .quad 0x00a
    .quad ele2
ele2:
    .quad 0x0b0
    .quad ele3
ele3:
    .quad 0xc00
    .quad 0

#main function

main:
    irmovq ele1, %rdi
    call sum_list
    ret

#sum_list function

sum_list:
    irmovq $0, %rax
    jmp test

loop:
    mrmovq (%rdi), %rsi
    addq %rsi, %rax
    mrmovq 8(%rdi), %rdi

test:
    andq %rdi, %rdi
    jne loop
    ret

#set initial adress of %rsp

    .pos 0x200
stack:

最后需要多打一个换行才能过编译，我也不知道为什么（

##################################################################
#initialization

.pos 0
irmovq stack, %rsp
call main
halt


#sample linked list

.align 8
ele1:
    .quad 0x00a
    .quad ele2
ele2:
    .quad 0x0b0
    .quad ele3
ele3:
    .quad 0xc00
    .quad 0

#main function
main:
    irmovq ele1, %rdi
    irmovq $0, %rax
    call rsum_list
    ret

#recursively calculate the sum of a list

rsum_list:
    pushq %rbp
    andq %rdi, %rdi
    je return
    mrmovq (%rdi), %rbp
    addq %rbp, %rax
    mrmovq 8(%rdi), %rdi
    call rsum_list
return:
    popq %rbp
    ret

#set initial adress of %rsp

    .pos 0x200
stack:

注意递归结束的时候，需要恢复被调用者保存寄存器的原始值

/* copy_block - Copy src to dest and return xor checksum of src */
long copy_block(long *src, long *dest, long len)
{
    long result = 0;
    while (len > 0) {
	long val = *src++;
	*dest++ = val;
	result ^= val;
	len--;
    }
    return result;
}
/* $end examples */

##################################################################
#initialization

.pos 0
irmovq stack, %rsp
call main
halt

#sample

.align 8
# Source block
src:
    .quad 0x00a
    .quad 0x0b0
    .quad 0xc00
# Destination block
dest:
    .quad 0x111
    .quad 0x222
    .quad 0x333

#main function

main:
    irmovq src, %rdi
    irmovq dest, %rsi
    irmovq $3, %rdx
    irmovq $0, %rax
    irmovq $8, %rcx
    irmovq $1, %r8
    call copy_block
    ret

#copy function

copy_block:
    pushq %rbx
test:
    andq %rdx, %rdx
    je return
loop:
    mrmovq (%rdi), %rbx
    xorq %rbx, %rax
    rmmovq %rbx, (%rsi)
    addq %rcx, %rdi
    addq %rcx, %rsi
    subq %r8, %rdx
    jmp test
return:
    popq %rbx
    ret

    .pos 0x200
stack:

Part B iaddq的实现

给定你SEQ的实现，要求你补充iaddq指令(即将寄存器加上一个立即数)的实现

按照SEQ的步骤，一步一步判断每个相关信号的值就行

shell中使用以下指令进行测试

make  VERSION=full
./ssim -t ../y86-code/asumi.yo
cd ../y86-code; make testssim

#/* $begin seq-all-hcl */
####################################################################
#  HCL Description of Control for Single Cycle Y86-64 Processor SEQ   #
#  Copyright (C) Randal E. Bryant, David R. O'Hallaron, 2010       #
####################################################################

## Your task is to implement the iaddq instruction
## The file contains a declaration of the icodes
## for iaddq (IIADDQ)
## Your job is to add the rest of the logic to make it work

####################################################################
#    C Include's.  Don't alter these                               #
####################################################################

quote '#include <stdio.h>'
quote '#include "isa.h"'
quote '#include "sim.h"'
quote 'int sim_main(int argc, char *argv[]);'
quote 'word_t gen_pc(){return 0;}'
quote 'int main(int argc, char *argv[])'
quote '  {plusmode=0;return sim_main(argc,argv);}'

####################################################################
#    Declarations.  Do not change/remove/delete any of these       #
####################################################################

##### Symbolic representation of Y86-64 Instruction Codes #############
wordsig INOP 	'I_NOP'
wordsig IHALT	'I_HALT'
wordsig IRRMOVQ	'I_RRMOVQ'
wordsig IIRMOVQ	'I_IRMOVQ'
wordsig IRMMOVQ	'I_RMMOVQ'
wordsig IMRMOVQ	'I_MRMOVQ'
wordsig IOPQ	'I_ALU'
wordsig IJXX	'I_JMP'
wordsig ICALL	'I_CALL'
wordsig IRET	'I_RET'
wordsig IPUSHQ	'I_PUSHQ'
wordsig IPOPQ	'I_POPQ'
# Instruction code for iaddq instruction
wordsig IIADDQ	'I_IADDQ'

##### Symbolic represenations of Y86-64 function codes                  #####
wordsig FNONE    'F_NONE'        # Default function code

##### Symbolic representation of Y86-64 Registers referenced explicitly #####
wordsig RRSP     'REG_RSP'    	# Stack Pointer
wordsig RNONE    'REG_NONE'   	# Special value indicating "no register"

##### ALU Functions referenced explicitly                            #####
wordsig ALUADD	'A_ADD'		# ALU should add its arguments

##### Possible instruction status values                             #####
wordsig SAOK	'STAT_AOK'	# Normal execution
wordsig SADR	'STAT_ADR'	# Invalid memory address
wordsig SINS	'STAT_INS'	# Invalid instruction
wordsig SHLT	'STAT_HLT'	# Halt instruction encountered

##### Signals that can be referenced by control logic ####################

##### Fetch stage inputs		#####
wordsig pc 'pc'				# Program counter
##### Fetch stage computations		#####
wordsig imem_icode 'imem_icode'		# icode field from instruction memory
wordsig imem_ifun  'imem_ifun' 		# ifun field from instruction memory
wordsig icode	  'icode'		# Instruction control code
wordsig ifun	  'ifun'		# Instruction function
wordsig rA	  'ra'			# rA field from instruction
wordsig rB	  'rb'			# rB field from instruction
wordsig valC	  'valc'		# Constant from instruction
wordsig valP	  'valp'		# Address of following instruction
boolsig imem_error 'imem_error'		# Error signal from instruction memory
boolsig instr_valid 'instr_valid'	# Is fetched instruction valid?

##### Decode stage computations		#####
wordsig valA	'vala'			# Value from register A port
wordsig valB	'valb'			# Value from register B port

##### Execute stage computations	#####
wordsig valE	'vale'			# Value computed by ALU
boolsig Cnd	'cond'			# Branch test

##### Memory stage computations		#####
wordsig valM	'valm'			# Value read from memory
boolsig dmem_error 'dmem_error'		# Error signal from data memory


####################################################################
#    Control Signal Definitions.                                   #
####################################################################

################ Fetch Stage     ###################################

# Determine instruction code
word icode = [
	imem_error: INOP;
	1: imem_icode;		# Default: get from instruction memory
];

# Determine instruction function
word ifun = [
	imem_error: FNONE;
	1: imem_ifun;		# Default: get from instruction memory
];

bool instr_valid = icode in 
	{ INOP, IHALT, IRRMOVQ, IIRMOVQ, IRMMOVQ, IMRMOVQ,
	       IOPQ, IJXX, ICALL, IRET, IPUSHQ, IPOPQ, IIADDQ};

# Does fetched instruction require a regid byte?
bool need_regids =
	icode in { IRRMOVQ, IOPQ, IPUSHQ, IPOPQ, 
		     IIRMOVQ, IRMMOVQ, IMRMOVQ , IIADDQ};

# Does fetched instruction require a constant word?
bool need_valC =
	icode in { IIRMOVQ, IRMMOVQ, IMRMOVQ, IJXX, ICALL , IIADDQ};

################ Decode Stage    ###################################

## What register should be used as the A source?
word srcA = [
	icode in { IRRMOVQ, IRMMOVQ, IOPQ, IPUSHQ  } : rA;
	icode in { IPOPQ, IRET } : RRSP;
	1 : RNONE; # Don't need register
];

## What register should be used as the B source?
word srcB = [
	icode in { IOPQ, IRMMOVQ, IMRMOVQ, IIADDQ  } : rB;
	icode in { IPUSHQ, IPOPQ, ICALL, IRET } : RRSP;
	1 : RNONE;  # Don't need register
];

## What register should be used as the E destination?
word dstE = [
	icode in { IRRMOVQ } && Cnd : rB;
	icode in { IIRMOVQ, IOPQ, IIADDQ} : rB;
	icode in { IPUSHQ, IPOPQ, ICALL, IRET } : RRSP;
	1 : RNONE;  # Don't write any register
];

## What register should be used as the M destination?
word dstM = [
	icode in { IMRMOVQ, IPOPQ } : rA;
	1 : RNONE;  # Don't write any register
];

################ Execute Stage   ###################################

## Select input A to ALU
word aluA = [
	icode in { IRRMOVQ, IOPQ } : valA;
	icode in { IIRMOVQ, IRMMOVQ, IMRMOVQ , IIADDQ} : valC;
	icode in { ICALL, IPUSHQ } : -8;
	icode in { IRET, IPOPQ } : 8;
	# Other instructions don't need ALU
];

## Select input B to ALU
word aluB = [
	icode in { IRMMOVQ, IMRMOVQ, IOPQ, ICALL, 
		      IPUSHQ, IRET, IPOPQ , IIADDQ} : valB;
	icode in { IRRMOVQ, IIRMOVQ } : 0;
	# Other instructions don't need ALU
];

## Set the ALU function
word alufun = [
	icode == IOPQ : ifun;
	1 : ALUADD;
];

## Should the condition codes be updated?
bool set_cc = icode in { IOPQ , IIADDQ};

################ Memory Stage    ###################################

## Set read control signal
bool mem_read = icode in { IMRMOVQ, IPOPQ, IRET };

## Set write control signal
bool mem_write = icode in { IRMMOVQ, IPUSHQ, ICALL };

## Select memory address
word mem_addr = [
	icode in { IRMMOVQ, IPUSHQ, ICALL, IMRMOVQ } : valE;
	icode in { IPOPQ, IRET } : valA;
	# Other instructions don't need address
];

## Select memory input data
word mem_data = [
	# Value from register
	icode in { IRMMOVQ, IPUSHQ } : valA;
	# Return PC
	icode == ICALL : valP;
	# Default: Don't write anything
];

## Determine instruction status
word Stat = [
	imem_error || dmem_error : SADR;
	!instr_valid: SINS;
	icode == IHALT : SHLT;
	1 : SAOK;
];

################ Program Counter Update ############################

## What address should instruction be fetched at

word new_pc = [
	# Call.  Use instruction constant
	icode == ICALL : valC;
	# Taken branch.  Use instruction constant
	icode == IJXX && Cnd : valC;
	# Completion of RET instruction.  Use value from stack
	icode == IRET : valM;
	# Default: Use incremented PC
	1 : valP;
];
#/* $end seq-all-hcl */

Part C Y86-64程序性能优化

写在前面

这个lab给定了你流水线化的控制代码以及一段代码的C和Y86-64实现，要求你优化流水线的控制代码和汇编代码，提高其运行效率

make  VERSION=full
cd ../ptest; make SIM=../pipe/psim
cd ../ptest; make SIM=../pipe/psim TFLAGS=-i

可以对修改后的处理器进行测试

../misc/yas ncopy.ys && ./check-len.pl < ncopy.yo 检查汇编代码是否超过1000Byte的限制

./correctness.pl检查汇编代码的正确性

make drivers && ./benchmark.pl进行本地跑分，计算CPE

得分细则如下

C代码如下，函数的功能是将src开始的len个元素全部拷贝到dst对应地址中，并返回源数据中正数个数

/* $begin ncopy */
/*
 * ncopy - copy src to dst, returning number of positive ints
 * contained in src array.
 */
word_t ncopy(word_t *src, word_t *dst, word_t len)
{
    word_t count = 0;
    word_t val;

    while (len > 0) {
	val = *src++;
	*dst++ = val;
	if (val > 0)
	    count++;
	len--;
    }
    return count;
}
/* $end ncopy */

Y86-64汇编原始代码

##################################################################
# %rdi = src, %rsi = dst, %rdx = len
# You can modify this portion
	# Loop header
	xorq %rax,%rax		# count = 0;
	andq %rdx,%rdx		# len <= 0?
	jle Done		# if so, goto Done:

Loop:	
    mrmovq (%rdi), %r10	# read val from src...
	rmmovq %r10, (%rsi)	# ...and store it to dst
	andq %r10, %r10		# val <= 0?
	jle Npos		# if so, goto Npos:
	irmovq $1, %r10
	addq %r10, %rax		# count++
Npos:	
	irmovq $1, %r10
	subq %r10, %rdx		# len--
	irmovq $8, %r10
	addq %r10, %rdi		# src++
	addq %r10, %rsi		# dst++
	andq %rdx,%rdx		# len > 0?
	jg Loop			# if so, goto Loop:

跑分结果如下：

Average CPE 15.18 Score 0.0/60.0

你都交原始代码了还想得分？(

使用iaddq指令

我们用Part B中相同的步骤，修改 pipe-full.hcl引入iaddq指令，减少向寄存器反复写入常数的开销

##################################################################
# You can modify this portion
	# Loop header
	xorq %rax,%rax		# count = 0;
	andq %rdx,%rdx		# len <= 0?
	jle Done		# if so, goto Done:

Loop:	
    mrmovq (%rdi), %r10	# read val from src...
	rmmovq %r10, (%rsi)	# ...and store it to dst
	andq %r10, %r10		# val <= 0?
	jle Npos		# if so, goto Npos:	
    iaddq $1, %rax      # count++
Npos:
    iaddq $-1, %rdx     # len--
	irmovq $8, %r10
	iaddq $8, %rdi		# src++
	iaddq $8, %rsi		# dst++
	andq %rdx,%rdx		# len > 0?
	jg Loop			# if so, goto Loop:

Average CPE 13.70 Score 0.0/60.0

优化后结果如下，性能略有提升，但仍然是0分

循环展开以及用条件传送替换条件跳转

考虑对源代码进行 $8 \times 8$的循环展开，同时使用不同的寄存器存储拷贝的值，减少循环判断和数据相关性

同时，对于统计正数这一部分，我们可以简单地使用条件传送而非条件跳转，避免分支预测错误带来的巨大性能损失

##################################################################
	xorq %rax,%rax		# count = 0;
	andq %rdx,%rdx		# len <= 0?
	jle Done		# if so, goto Done:
    irmovq $1, %r8  #store const 1 in %r8

Judge:
    iaddq $-8, %rdx
    jl Endloop

Loop:
    mrmovq (%rdi), %rbx
    mrmovq 8(%rdi), %rbp
    mrmovq 16(%rdi), %r9
    mrmovq 24(%rdi), %r10
    mrmovq 32(%rdi), %r11
    mrmovq 40(%rdi), %r12
    mrmovq 48(%rdi), %r13
    mrmovq 56(%rdi), %r14

    irmovq $0, %rcx
    andq %rbx, %rbx
    cmovg %r8, %rcx
    addq %rcx, %rax

    irmovq $0, %rcx
    andq %rbp, %rbp
    cmovg %r8, %rcx
    addq %rcx, %rax

    irmovq $0, %rcx
    andq %r9, %r9
    cmovg %r8, %rcx
    addq %rcx, %rax

    irmovq $0, %rcx
    andq %r10, %r10
    cmovg %r8, %rcx
    addq %rcx, %rax

    irmovq $0, %rcx
    andq %r11, %r11
    cmovg %r8, %rcx
    addq %rcx, %rax

    irmovq $0, %rcx
    andq %r12, %r12
    cmovg %r8, %rcx
    addq %rcx, %rax

    irmovq $0, %rcx
    andq %r13, %r13
    cmovg %r8, %rcx
    addq %rcx, %rax

    irmovq $0, %rcx
    andq %r14, %r14
    cmovg %r8, %rcx
    addq %rcx, %rax

    rmmovq %rbx, (%rsi)
    rmmovq %rbp, 8(%rsi)
    rmmovq %r9, 16(%rsi)
    rmmovq %r10, 24(%rsi)
    rmmovq %r11, 32(%rsi)
    rmmovq %r12, 40(%rsi)
    rmmovq %r13, 48(%rsi)
    rmmovq %r14, 56(%rsi)

	iaddq $64, %rdi		# src+=8
	iaddq $64, %rsi		# dst+=8
	jmp Judge

Endloop:
    iaddq $8, %rdx

Judge2:
    andq %rdx, %rdx
    jle Done
Loop2:
    mrmovq (%rdi), %rbx
    irmovq $0, %rcx
    andq %rbx, %rbx
    cmovg %r8, %rcx
    addq %rcx, %rax
    rmmovq %rbx, (%rsi)
    iaddq $8, %rdi
    iaddq $8, %rsi
    iaddq $-1, %rdx
    jmp Judge2

CPE以及得分如下

Average CPE 9.98 Score 10.5/60.0

我们发现，在拷贝的数量比较少的时候，CPE的值相当大，甚至比最原始的汇编代码性能还要差，同时，在注释掉对于剩下 $len %8$个数的拷贝与统计的时候，CPE下降到了6.79，足以得到满分，说明该程序性能的瓶颈在于对余数的处理

对于余数的处理

考虑对于最后8个数不采用循环，直接类似循环展开依次拷贝并统计

##################################################################
Endloop:
    iaddq $8, %rdx
    jle Done

    mrmovq (%rdi), %rbx
    irmovq $0, %rcx
    andq %rbx, %rbx
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %rbx, (%rsi)
    jle Done

    mrmovq 8(%rdi), %rbp
    irmovq $0, %rcx
    andq %rbp, %rbp
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %rbp, 8(%rsi)
    jle Done

    mrmovq 16(%rdi), %r9
    irmovq $0, %rcx
    andq %r9, %r9
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %r9, 16(%rsi)
    jle Done

    mrmovq 24(%rdi), %r10
    irmovq $0, %rcx
    andq %r10, %r10
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %r10, 24(%rsi)
    jle Done

    mrmovq 32(%rdi), %r11
    irmovq $0, %rcx
    andq %r11, %r11
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %r11, 32(%rsi)
    jle Done

    mrmovq 40(%rdi), %r12
    irmovq $0, %rcx
    andq %r12, %r12
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %r12, 40(%rsi)
    jle Done

    mrmovq 48(%rdi), %r13
    irmovq $0, %rcx
    andq %r13, %r13
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %r13, 48(%rsi)
    jle Done

    mrmovq 56(%rdi), %r14
    irmovq $0, %rcx
    andq %r14, %r14
    cmovg %r8, %rcx
    addq %rcx, %rax
    iaddq $-1, %rdx
    rmmovq %r14, 56(%rsi)

Average CPE 9.04 Score 29.3/60.0

性能略有提升

再考虑到该处理器对于分支的预测是预测进入，而对于后八个数进入 Done的可能性更小，可能会导致分支预测出错导致性能下降，所以我们将跳转改为更可能的进入下一个数的处理

##################################################################
Endloop:
    iaddq $8, %rdx
    jle Done

    mrmovq (%rdi), %rbx
    irmovq $0, %rcx
    andq %rbx, %rbx
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %rbx, (%rsi)
    jg calc2
    jmp Done

calc2:
    mrmovq 8(%rdi), %rbp
    irmovq $0, %rcx
    andq %rbp, %rbp
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %rbp, 8(%rsi)
    jg calc3
    jmp Done

calc3:
    mrmovq 16(%rdi), %r9
    irmovq $0, %rcx
    andq %r9, %r9
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %r9, 16(%rsi)
    jg calc4
    jmp Done

calc4:
    mrmovq 24(%rdi), %r10
    irmovq $0, %rcx
    andq %r10, %r10
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %r10, 24(%rsi)
    jg calc5
    jmp Done

calc5:
    mrmovq 32(%rdi), %r11
    irmovq $0, %rcx
    andq %r11, %r11
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %r11, 32(%rsi)
    jg calc6
    jmp Done

calc6:
    mrmovq 40(%rdi), %r12
    irmovq $0, %rcx
    andq %r12, %r12
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %r12, 40(%rsi)
    jg calc7
    jmp Done

calc7:
    mrmovq 48(%rdi), %r13
    irmovq $0, %rcx
    andq %r13, %r13
    cmovg %r8, %rcx
    addq %rcx, %rax    
    iaddq $-1, %rdx
    rmmovq %r13, 48(%rsi)
    jg calc8
    jmp Done

calc8:
    mrmovq 56(%rdi), %r14
    irmovq $0, %rcx
    andq %r14, %r14
    cmovg %r8, %rcx
    addq %rcx, %rax
    iaddq $-1, %rdx
    rmmovq %r14, 56(%rsi)

Average CPE 8.92 Score 31.5/60.0

性能也有所提升

一些奇怪的优化

发现从条件传送改回条件跳转效率反而增加了。。。可能是条件传送要求对 %rcx反复进行清零，传送，加法，相关性过高，操作数量也变多了，反而不如条件跳转（

##################################################################
    andq %rbx, %rbx
    jle Test2
    iaddq $1, %rax

Test2:
    andq %rbp, %rbp
    jle Test3
    iaddq $1, %rax

类似这样修改就行

Average CPE 8.50 Score 40.0/60.0

效率又提升了

然后发现实验驱动在进入ncopy时%rax的值初始为0，且测试数据中不存在负长度的情况，因此为了榨分可以省掉循环之前的初始化与检查（按一般调用约定，健壮写法仍应显式把返回值寄存器清零并处理len <= 0）

Average CPE 8.13 Score 47.4/60.0

我很难受，叫基米来

现在代码的限制瓶颈是处理余数时由于不知道需要处理的个数，我们只能将数据从内存中加载到寄存器后就立即使用检查其是否大于0，这产生了数据依赖

到了这里已经燃尽了，尝试过将余数按照$2 \times 2$循环展开效率反而下降了，想着提前将余数从内存放进寄存器来减少数据相关，但是会超过编码长度限制，是时候询问伟大的哈基米3.0pro了（

Gemini3.0pro告诉我，可以用类似二叉树的结构高效地处理余数，具体来说，可以先将余数按照0-3和4-7分为左右儿子，对于右儿子，可以直接加载0-3的数进入寄存器中，进而减小了数据依赖，每个节点继续向下分，对于大小为2的右儿子也可以直接加载左儿子寄存器

同时发现循环展开中专门为循环判断设计函数进行跳转是不必要的，可以直接将判断写在循环的末尾

循环结尾改为

##################################################################
Test9:
	iaddq $64, %rdi		# src+=8
	iaddq $64, %rsi		# dst+=8
    iaddq $-8, %rdx
	jge Loop

使用二叉树结构处理余数部分汇编代码如下

##################################################################
Endloop:
    # -8 <= %rdx <= -1
    iaddq $4, %rdx
    jge Four_to_Seven
    iaddq $4, %rdx
    jmp Zero_to_Three
Four_to_Seven:
    mrmovq (%rdi), %rbx
    mrmovq 8(%rdi), %rbp
    mrmovq 16(%rdi), %r9
    mrmovq 24(%rdi), %r10

    rmmovq %rbx, (%rsi)
    rmmovq %rbp, 8(%rsi)
    rmmovq %r9, 16(%rsi)
    rmmovq %r10, 24(%rsi)

    andq %rbx, %rbx
    jle Notadd1
    iaddq $1, %rax
Notadd1:
    andq %rbp, %rbp
    jle Notadd2
    iaddq $1, %rax
Notadd2:
    andq %r9, %r9
    jle Notadd3
    iaddq $1, %rax
Notadd3:
    andq %r10, %r10
    jle Notadd4
    iaddq $1, %rax
Notadd4:
    iaddq $32, %rdi
    iaddq $32, %rsi

Zero_to_Three:
    # 0 <= %rdx <= 3
    iaddq $-2, %rdx
    jge Two_to_Three
    iaddq $2, %rdx
    jmp Zero_to_One

Two_to_Three:
    mrmovq (%rdi), %rbx
    mrmovq 8(%rdi), %rbp
    andq %rbx, %rbx
    jle Notadd1_2
    iaddq $1, %rax
Notadd1_2:
    andq %rbp, %rbp
    jle Notadd2_2
    iaddq $1, %rax
Notadd2_2:
    rmmovq %rbx, (%rsi)
    rmmovq %rbp, 8(%rsi)
    iaddq $16, %rdi
    iaddq $16, %rsi

Zero_to_One:
    andq %rdx, %rdx
    je Done
    mrmovq (%rdi), %rbx
    rmmovq %rbx, (%rsi)
    andq %rbx, %rbx
    jle Done
    iaddq $1, %rax

Average CPE 7.90 Score 52.1/60.0

尝试在余数为2和3的时候进行特判，避免进入左子树

##################################################################
Two_to_Three:
    mrmovq (%rdi), %rbx
    mrmovq 8(%rdi), %rbp
    je Handle_2
    mrmovq 16(%rdi), %r9
    rmmovq %r9, 16(%rsi)
    andq %r9, %r9
    jle Handle_2
    iaddq $1, %rax
Handle_2:
    rmmovq %rbx, (%rsi)
    andq %rbx, %rbx
    jle Notadd1_2
    iaddq $1, %rax
Notadd1_2:
    rmmovq %rbp, 8(%rsi)
    andq %rbp, %rbp
    jle Done
    iaddq $1, %rax
    jmp Done

Average CPE 7.80 Score 54.0/60.0

同时我们发现在处理的长度特别小的时候，CPE相当大

ncopy 0 26 1 33 33.00 2 33 16.50 3 39 13.00 4 46 11.50 5 53 10.60

由于处理器的分支预测逻辑是预测进入，所以我们尝试修改为预测进入左子树

##################################################################
Endloop:
    # -8 <= %rdx <= -1
    iaddq $4, %rdx
    jl Pre_Zero_to_Three

Four_to_Seven:
    mrmovq (%rdi), %rbx
    mrmovq 8(%rdi), %rbp
    mrmovq 16(%rdi), %r9
    mrmovq 24(%rdi), %r10

    rmmovq %rbx, (%rsi)
    rmmovq %rbp, 8(%rsi)
    rmmovq %r9, 16(%rsi)
    rmmovq %r10, 24(%rsi)
    
    andq %rbx, %rbx
    jle Notadd1
    iaddq $1, %rax
Notadd1:
    andq %rbp, %rbp
    jle Notadd2
    iaddq $1, %rax
Notadd2:
    andq %r9, %r9
    jle Notadd3
    iaddq $1, %rax
Notadd3:
    andq %r10, %r10
    jle Notadd4
    iaddq $1, %rax
Notadd4:
    iaddq $32, %rdi
    iaddq $32, %rsi
    jmp Zero_to_Three

Pre_Zero_to_Three:
    iaddq $4, %rdx

Zero_to_Three:
    # 0 <= %rdx <= 3
    iaddq $-2, %rdx
    jl Zero_to_One

Two_to_Three:
    mrmovq (%rdi), %rbx
    mrmovq 8(%rdi), %rbp
    je Handle_2
    mrmovq 16(%rdi), %r9
    rmmovq %r9, 16(%rsi)
    andq %r9, %r9
    jle Handle_2
    iaddq $1, %rax
Handle_2:
    rmmovq %rbx, (%rsi)
    andq %rbx, %rbx
    jle Notadd1_2
    iaddq $1, %rax
Notadd1_2:
    rmmovq %rbp, 8(%rsi)
    andq %rbp, %rbp
    jle Done
    iaddq $1, %rax
    jmp Done

Zero_to_One:
    iaddq $2, %rdx
    je Done
    mrmovq (%rdi), %rbx
    rmmovq %rbx, (%rsi)
    andq %rbx, %rbx
    jle Done
    iaddq $1, %rax

Average CPE 7.65 Score 57.1/60.0

调到这里已经产生生理性不适了，再写下去就要堆成屎山了，后面的区域以后再来探索吧（（（

遗憾离场

#/* $begin ncopy-ys */
##################################################################
# ncopy.ys - Copy a src block of len words to dst.
# Return the number of positive words (>0) contained in src.
#
# Include your name and ID here.
#
# Describe how and why you modified the baseline code.
#
##################################################################
# Do not modify this portion
# Function prologue.
# %rdi = src, %rsi = dst, %rdx = len
ncopy:

##################################################################
# You can modify this portion
	# Loop header
	# count = 0;
	# len <= 0?
	# if so, goto Done:

    iaddq $-8, %rdx
    jl Endloop

Loop:
    mrmovq (%rdi), %rbx
    mrmovq 8(%rdi), %rbp
    mrmovq 16(%rdi), %r9
    mrmovq 24(%rdi), %r10
    mrmovq 32(%rdi), %r11
    mrmovq 40(%rdi), %r12
    mrmovq 48(%rdi), %r13
    mrmovq 56(%rdi), %r14

    rmmovq %rbx, (%rsi)
    rmmovq %rbp, 8(%rsi)
    rmmovq %r9, 16(%rsi)
    rmmovq %r10, 24(%rsi)
    rmmovq %r11, 32(%rsi)
    rmmovq %r12, 40(%rsi)
    rmmovq %r13, 48(%rsi)
    rmmovq %r14, 56(%rsi)

    andq %rbx, %rbx
    jle Test2
    iaddq $1, %rax

Test2:
    andq %rbp, %rbp
    jle Test3
    iaddq $1, %rax

Test3:
    andq %r9, %r9
    jle Test4
    iaddq $1, %rax

Test4:
    andq %r10, %r10
    jle Test5
    iaddq $1, %rax

Test5:
    andq %r11, %r11
    jle Test6
    iaddq $1, %rax

Test6:
    andq %r12, %r12
    jle Test7
    iaddq $1, %rax

Test7:
    andq %r13, %r13
    jle Test8
    iaddq $1, %rax

Test8:
    andq %r14, %r14
    jle Test9
    iaddq $1, %rax

Test9:
	iaddq $64, %rdi		# src+=8
	iaddq $64, %rsi		# dst+=8
    iaddq $-8, %rdx
	jge Loop

# handle remainder
Endloop:
    # -8 <= %rdx <= -1
    iaddq $4, %rdx
    jl Pre_Zero_to_Three

Four_to_Seven:
    mrmovq (%rdi), %rbx
    mrmovq 8(%rdi), %rbp
    mrmovq 16(%rdi), %r9
    mrmovq 24(%rdi), %r10

    rmmovq %rbx, (%rsi)
    rmmovq %rbp, 8(%rsi)
    rmmovq %r9, 16(%rsi)
    rmmovq %r10, 24(%rsi)
    
    andq %rbx, %rbx
    jle Notadd1
    iaddq $1, %rax
Notadd1:
    andq %rbp, %rbp
    jle Notadd2
    iaddq $1, %rax
Notadd2:
    andq %r9, %r9
    jle Notadd3
    iaddq $1, %rax
Notadd3:
    andq %r10, %r10
    jle Notadd4
    iaddq $1, %rax
Notadd4:
    iaddq $32, %rdi
    iaddq $32, %rsi
    jmp Zero_to_Three

Pre_Zero_to_Three:
    iaddq $4, %rdx

Zero_to_Three:
    # 0 <= %rdx <= 3
    iaddq $-2, %rdx
    jl Zero_to_One

Two_to_Three:
    mrmovq (%rdi), %rbx
    mrmovq 8(%rdi), %rbp
    je Handle_2
    mrmovq 16(%rdi), %r9
    rmmovq %r9, 16(%rsi)
    andq %r9, %r9
    jle Handle_2
    iaddq $1, %rax
Handle_2:
    rmmovq %rbx, (%rsi)
    andq %rbx, %rbx
    jle Notadd1_2
    iaddq $1, %rax
Notadd1_2:
    rmmovq %rbp, 8(%rsi)
    andq %rbp, %rbp
    jle Done
    iaddq $1, %rax
    jmp Done

Zero_to_One:
    iaddq $2, %rdx
    je Done
    mrmovq (%rdi), %rbx
    rmmovq %rbx, (%rsi)
    andq %rbx, %rbx
    jle Done
    iaddq $1, %rax

##################################################################
# Do not modify the following section of code
# Function epilogue.
Done:
	ret
##################################################################
# Keep the following label at the end of your function
End:
#/* $end ncopy-ys */
    

规则：对于每个$phase$，你都需要输入一个字符串，使得$explode_bomb$函数不被运行

在bomb目录下使用objdump -d bomb > bomb.s得到反汇编文件$bomb.s$

$shell$ 中使用 gdb bomb进入$gdb$调试

phase_1

  0000000000400ee0 <phase_1>:
  400ee0:	48 83 ec 08          	sub    $0x8,%rsp
  400ee4:	be 00 24 40 00       	mov    $0x402400,%esi
  400ee9:	e8 4a 04 00 00       	call   401338 <strings_not_equal>
  400eee:	85 c0                	test   %eax,%eax
  400ef0:	74 05                	je     400ef7 <phase_1+0x17>
  400ef2:	e8 43 05 00 00       	call   40143a <explode_bomb>
  400ef7:	48 83 c4 08          	add    $0x8,%rsp
  400efb:	c3                   	ret

先是额外调整8字节栈空间以满足调用时的栈对齐要求，然后进入了$strings_not_equal$函数中；返回地址已经由调用phase_1时的call指令压栈

  0000000000401338 <strings_not_equal>:
  401338:	41 54                	push   %r12
  40133a:	55                   	push   %rbp
  40133b:	53                   	push   %rbx
  40133c:	48 89 fb             	mov    %rdi,%rbx
  40133f:	48 89 f5             	mov    %rsi,%rbp
  401342:	e8 d4 ff ff ff       	call   40131b <string_length>
  401347:	41 89 c4             	mov    %eax,%r12d
  40134a:	48 89 ef             	mov    %rbp,%rdi
  40134d:	e8 c9 ff ff ff       	call   40131b <string_length>
  401352:	ba 01 00 00 00       	mov    $0x1,%edx
  401357:	41 39 c4             	cmp    %eax,%r12d
  40135a:	75 3f                	jne    40139b <strings_not_equal+0x63>
  40135c:	0f b6 03             	movzbl (%rbx),%eax
  40135f:	84 c0                	test   %al,%al
  401361:	74 25                	je     401388 <strings_not_equal+0x50>
  401363:	3a 45 00             	cmp    0x0(%rbp),%al
  401366:	74 0a                	je     401372 <strings_not_equal+0x3a>
  401368:	eb 25                	jmp    40138f <strings_not_equal+0x57>
  40136a:	3a 45 00             	cmp    0x0(%rbp),%al
  40136d:	0f 1f 00             	nopl   (%rax)
  401370:	75 24                	jne    401396 <strings_not_equal+0x5e>
  401372:	48 83 c3 01          	add    $0x1,%rbx
  401376:	48 83 c5 01          	add    $0x1,%rbp
  40137a:	0f b6 03             	movzbl (%rbx),%eax
  40137d:	84 c0                	test   %al,%al
  40137f:	75 e9                	jne    40136a <strings_not_equal+0x32>
  401381:	ba 00 00 00 00       	mov    $0x0,%edx
  401386:	eb 13                	jmp    40139b <strings_not_equal+0x63>
  401388:	ba 00 00 00 00       	mov    $0x0,%edx
  40138d:	eb 0c                	jmp    40139b <strings_not_equal+0x63>
  40138f:	ba 01 00 00 00       	mov    $0x1,%edx
  401394:	eb 05                	jmp    40139b <strings_not_equal+0x63>
  401396:	ba 01 00 00 00       	mov    $0x1,%edx
  40139b:	89 d0                	mov    %edx,%eax
  40139d:	5b                   	pop    %rbx
  40139e:	5d                   	pop    %rbp
  40139f:	41 5c                	pop    %r12
  4013a1:	c3                   	ret

阅读地址在$401338$的$strings_not_equal$并结合函数名推断，该函数将$%rdi$和$%rsi$指向的地址的字符串进行比较，若相等则将$%rax$设为0，反之将$%rax$设为1

所以这段汇编代码在$%edi$和$%esi$指向的字符串相同的时候不会爆炸，只需输入内存$0x402400$中的字符串即可

(gdb) x/s 0x402400

得到 Border relations with Canada have never been better. 即为本题答案

phase_2

 0000000000400efc <phase_2>:
  400efc:	55                   	push   %rbp
  400efd:	53                   	push   %rbx
  400efe:	48 83 ec 28          	sub    $0x28,%rsp
  400f02:	48 89 e6             	mov    %rsp,%rsi
  400f05:	e8 52 05 00 00       	call   40145c <read_six_numbers>

程序首先将$%rbp$和$%rbx$压入栈中保存状态，并为栈分配了40字节的空间，并将$%rsp$栈指针放入$%rsi$作为$read_six_numbers$的第二个参数

接下来我们来看$read_six_numbers$函数

 000000000040145c <read_six_numbers>:
  40145c:	48 83 ec 18          	sub    $0x18,%rsp
  401460:	48 89 f2             	mov    %rsi,%rdx //arg 3
  401463:	48 8d 4e 04          	lea    0x4(%rsi),%rcx //arg 4
  401467:	48 8d 46 14          	lea    0x14(%rsi),%rax
  40146b:	48 89 44 24 08       	mov    %rax,0x8(%rsp) //arg 8
  401470:	48 8d 46 10          	lea    0x10(%rsi),%rax
  401474:	48 89 04 24          	mov    %rax,(%rsp) //arg 7
  401478:	4c 8d 4e 0c          	lea    0xc(%rsi),%r9 //arg 6
  40147c:	4c 8d 46 08          	lea    0x8(%rsi),%r8 // arg 5
  401480:	be c3 25 40 00       	mov    $0x4025c3,%esi //arg 2
  401485:	b8 00 00 00 00       	mov    $0x0,%eax
  40148a:	e8 61 f7 ff ff       	call   400bf0 <__isoc99_sscanf@plt>
  40148f:	83 f8 05             	cmp    $0x5,%eax
  401492:	7f 05                	jg     401499 <read_six_numbers+0x3d>
  401494:	e8 a1 ff ff ff       	call   40143a <explode_bomb>
  401499:	48 83 c4 18          	add    $0x18,%rsp
  40149d:	c3                   	ret

查表发现其中部分寄存器为参数寄存器，已经在代码中标出

看到这里寄存器指向的地址有点混乱，于是我们进入gdb调试查看相关寄存器的值

通过b explode_bomb在爆炸函数前设置断点，得以保证在刚进入爆炸函数且还未爆炸之前得以停顿进而进行调试

我们随便输入一堆数，然后在断点处检查每个寄存器的值

发现

这类似C/C++中$scanf$的占位符，结合函数名和剩下6个参数寄存器，我们大胆推测这个函数以$%esi$为占位符，读入六个$int$并存放在其他六个参数寄存器中，依次在$%rdx$，$%rcx$，$%r8$，$%r9$和栈中的两个位置

我们手动模拟可以得到以下结果，设最初$%rsp$指向的地址为$p$

可以使用gdb进行验证，同时访问$(%rax)$的值发现是读入的数的个数

成功读入的个数传回$%rax$中，当读入的个数小于等于5时炸弹会爆炸，否则函数正常退出

继续回到$phase_2$中

  400f0a:	83 3c 24 01          	cmpl   $0x1,(%rsp)
  400f0e:	74 20                	je     400f30 <phase_2+0x34>
  400f10:	e8 25 05 00 00       	call   40143a <explode_bomb>
  400f15:	eb 19                	jmp    400f30 <phase_2+0x34>
  400f17:	8b 43 fc             	mov    -0x4(%rbx),%eax
  400f1a:	01 c0                	add    %eax,%eax
  400f1c:	39 03                	cmp    %eax,(%rbx)
  400f1e:	74 05                	je     400f25 <phase_2+0x29>
  400f20:	e8 15 05 00 00       	call   40143a <explode_bomb>
  400f25:	48 83 c3 04          	add    $0x4,%rbx
  400f29:	48 39 eb             	cmp    %rbp,%rbx
  400f2c:	75 e9                	jne    400f17 <phase_2+0x1b>
  400f2e:	eb 0c                	jmp    400f3c <phase_2+0x40>
  400f30:	48 8d 5c 24 04       	lea    0x4(%rsp),%rbx
  400f35:	48 8d 6c 24 18       	lea    0x18(%rsp),%rbp
  400f3a:	eb db                	jmp    400f17 <phase_2+0x1b>
  400f3c:	48 83 c4 28          	add    $0x28,%rsp
  400f40:	5b                   	pop    %rbx
  400f41:	5d                   	pop    %rbp
  400f42:	c3                   	ret

根据上图可以发现，$%rdx$指向的地址即为$%rsp$，即检查第一个数是否为1，若不是1则直接爆炸

此后将$%rbx$设置为$p+4$(指向第二个数)，$%rbp$设置为$p+24$(指向最后一个数的下一个地址)，并将执行的指令跳转到$*0x400f17$

将$%rax$设置为$%rbx$指向的前一个数，将$p$指向的值乘2以后与$%rbx$比较，若不相等直接爆炸

此后将$%rbx$指向下一个数，检查其若超出了读入的6个数地址范围则安全退出这个函数，否则重复上一行和这一行的内容

可以发现，这一段代码等价于从第二个数开始直到第六个数，检查其是否为前一个数的两倍，全部满足则能安全退出

因此只需要第一个数为1，后面的数每个都为前一个数两倍即可

故答案为 1 2 4 8 16 32

phase_3

 0000000000400f43 <phase_3>:
  400f43:	48 83 ec 18          	sub    $0x18,%rsp
  400f47:	48 8d 4c 24 0c       	lea    0xc(%rsp),%rcx
  400f4c:	48 8d 54 24 08       	lea    0x8(%rsp),%rdx
  400f51:	be cf 25 40 00       	mov    $0x4025cf,%esi
  400f56:	b8 00 00 00 00       	mov    $0x0,%eax
  400f5b:	e8 90 fc ff ff       	call   400bf0 <__isoc99_sscanf@plt>
  400f60:	83 f8 01             	cmp    $0x1,%eax
  400f63:	7f 05                	jg     400f6a <phase_3+0x27>
  400f65:	e8 d0 04 00 00       	call   40143a <explode_bomb>
  400f6a:	83 7c 24 08 07       	cmpl   $0x7,0x8(%rsp)
  400f6f:	77 3c                	ja     400fad <phase_3+0x6a>
  400f71:	8b 44 24 08          	mov    0x8(%rsp),%eax
  400f75:	ff 24 c5 70 24 40 00 	jmp    *0x402470(,%rax,8)
  400f7c:	b8 cf 00 00 00       	mov    $0xcf,%eax
  400f81:	eb 3b                	jmp    400fbe <phase_3+0x7b>
  400f83:	b8 c3 02 00 00       	mov    $0x2c3,%eax
  400f88:	eb 34                	jmp    400fbe <phase_3+0x7b>
  400f8a:	b8 00 01 00 00       	mov    $0x100,%eax
  400f8f:	eb 2d                	jmp    400fbe <phase_3+0x7b>
  400f91:	b8 85 01 00 00       	mov    $0x185,%eax
  400f96:	eb 26                	jmp    400fbe <phase_3+0x7b>
  400f98:	b8 ce 00 00 00       	mov    $0xce,%eax
  400f9d:	eb 1f                	jmp    400fbe <phase_3+0x7b>
  400f9f:	b8 aa 02 00 00       	mov    $0x2aa,%eax
  400fa4:	eb 18                	jmp    400fbe <phase_3+0x7b>
  400fa6:	b8 47 01 00 00       	mov    $0x147,%eax
  400fab:	eb 11                	jmp    400fbe <phase_3+0x7b>
  400fad:	e8 88 04 00 00       	call   40143a <explode_bomb>
  400fb2:	b8 00 00 00 00       	mov    $0x0,%eax
  400fb7:	eb 05                	jmp    400fbe <phase_3+0x7b>
  400fb9:	b8 37 01 00 00       	mov    $0x137,%eax
  400fbe:	3b 44 24 0c          	cmp    0xc(%rsp),%eax
  400fc2:	74 05                	je     400fc9 <phase_3+0x86>
  400fc4:	e8 71 04 00 00       	call   40143a <explode_bomb>
  400fc9:	48 83 c4 18          	add    $0x18,%rsp
  400fcd:	c3                   	ret

设最初$%rsp$指向的地址是p,先是分配了24字节的栈空间,此后$%rsp$，$%rcx$，$%rdx$，$%rsi$指向的地址分别为$p-18$,$p-6$,$p-10$,$0x4025cf$,$%rax$的值为0

我们使用 gdb x/s 0x4025cf发现gdb 返回的结果是 0x4025cf: "%d %d"，说明读入了两个数依次存放在$%rdx$和$%rcx$指向的地址中，若读入的数个数不大于1就爆炸

假设读入的两个数分别为$x$和$y$，$x$大于7也会爆炸

接下来将$%rax$也指向地址$p-10$(x)，然后有一条跳转指令，注意这是一条间接跳转，会让PC地址变为 $0x00402470 + 8 \times x$地址中存放的值

通过 (gdb) x/16x 0x402470 我们可以得到从$0x402470$开始16个单位的值

一个单位为4字节32位，16个单位即为8个64位的指针，结果如下

注意$x86-64$下使用的是小端法

我们不妨从最后一个$explode_bomb$函数开始看，想要不进入这个函数，就需要让最后$%rax$的值等于$%rcx$指向的值(y)

jmp *0x402470(,%rax,8)这一行后面都是对于$%rax$的赋值后跳转到判断$%rax$与y是否相等，所以我们只需要在输入时将y设置为对应跳转时$%rax$赋的值即可

如$x = 0$,$%rax=0xcf=207$或$x = 1$,$%rax = 0x137 = 311$ ...

所以本题一个可能的答案即为 0 207

phase_4

  40100c <phase_4>: 
  40100c:	48 83 ec 18          	sub    $0x18,%rsp
  401010:	48 8d 4c 24 0c       	lea    0xc(%rsp),%rcx
  401015:	48 8d 54 24 08       	lea    0x8(%rsp),%rdx
  40101a:	be cf 25 40 00       	mov    $0x4025cf,%esi
  40101f:	b8 00 00 00 00       	mov    $0x0,%eax
  401024:	e8 c7 fb ff ff       	call   400bf0 <__isoc99_sscanf@plt>
  401029:	83 f8 02             	cmp    $0x2,%eax
  40102c:	75 07                	jne    401035 <phase_4+0x29>
  40102e:	83 7c 24 08 0e       	cmpl   $0xe,0x8(%rsp)
  401033:	76 05                	jbe    40103a <phase_4+0x2e>
  401035:	e8 00 04 00 00       	call   40143a <explode_bomb>
  40103a:	ba 0e 00 00 00       	mov    $0xe,%edx
  40103f:	be 00 00 00 00       	mov    $0x0,%esi
  401044:	8b 7c 24 08          	mov    0x8(%rsp),%edi
  401048:	e8 81 ff ff ff       	call   400fce <func4>
  40104d:	85 c0                	test   %eax,%eax
  40104f:	75 07                	jne    401058 <phase_4+0x4c>
  401051:	83 7c 24 0c 00       	cmpl   $0x0,0xc(%rsp)
  401056:	74 05                	je     40105d <phase_4+0x51>
  401058:	e8 dd 03 00 00       	call   40143a <explode_bomb>
  40105d:	48 83 c4 18          	add    $0x18,%rsp
  401061:	c3                   	ret

同样设函数开始时$%rsp$指向的地址为p,在输入前$%rsp$,$%rcx$,$%rdx$指向的地址分别为$p-24$,$p-12$,$p-16$

$0x4025cf$中的格式为 "%d %d"，读入的个数不是2就会爆炸。设读入$%rdx$, $%rcx$中的值分别为$x$和$y$

$x$大于14时会发生爆炸，否则将$%rdx$的值设置为14，$%rsi$的值设置为0，$%rdi$的值设置为$x$，作为参数传入$func4$中

根据退出$func4$后的代码我们知道，只有在$%rax=0$且$p-12$这个地址的值为0的情况下才能安全退出

0000000000400fce <func4>:
 400fce:	48 83 ec 08          	sub    $0x8,%rsp
 400fd2:	89 d0                	mov    %edx,%eax
 400fd4:	29 f0                	sub    %esi,%eax
 400fd6:	89 c1                	mov    %eax,%ecx
 400fd8:	c1 e9 1f             	shr    $0x1f,%ecx
 400fdb:	01 c8                	add    %ecx,%eax
 400fdd:	d1 f8                	sar    $1,%eax
 400fdf:	8d 0c 30             	lea    (%rax,%rsi,1),%ecx
 400fe2:	39 f9                	cmp    %edi,%ecx
 400fe4:	7e 0c                	jle    400ff2 <func4+0x24>
 400fe6:	8d 51 ff             	lea    -0x1(%rcx),%edx
 400fe9:	e8 e0 ff ff ff       	call   400fce <func4>
 400fee:	01 c0                	add    %eax,%eax
 400ff0:	eb 15                	jmp    401007 <func4+0x39>
 400ff2:	b8 00 00 00 00       	mov    $0x0,%eax
 400ff7:	39 f9                	cmp    %edi,%ecx
 400ff9:	7d 0c                	jge    401007 <func4+0x39>
 400ffb:	8d 71 01             	lea    0x1(%rcx),%esi
 400ffe:	e8 cb ff ff ff       	call   400fce <func4>
 401003:	8d 44 00 01          	lea    0x1(%rax,%rax,1),%eax
 401007:	48 83 c4 08          	add    $0x8,%rsp
 40100b:	c3                   	ret

接下来是这个递归函数$func4$，我太菜了看不懂它叽里咕噜在说写什么，直接运用$OI$知识人肉反编译打表(

#include <bits/stdc++.h>

int rdi, rsi, rdx, rcx, rax;

void f() {
    rax = rdx;
    rax -= rsi;
    rcx = rax;
    rcx >>= 31;
    rax += rcx;
    rax >>= 1;
    rcx = rax + rsi;
    if (rcx <= rdi) goto x400ff2;
    rdx = rcx - 1;
    f(); 
    rax += rax;
    goto x401007;
    x400ff2:
    rax = 0;
    if (rcx >= rdi) goto x401007;
    rsi = rcx + 1;
    f();
    rax = rax + rax + 1;
    x401007:
    return;
}

int main() {
    for (int x = 0; x <= 3; x++) {
        for (int y = 0; y <= 3; y++) {
            rdi = x; rsi = 0; rdx = 14; rcx = y;
            f();
            std::cout << "x=" << x << " y=" << y << " rax=" << rax << '\n';
        }
    }
}

结果如下

x=0 y=0 rax=0
x=0 y=1 rax=0
x=0 y=2 rax=0
x=0 y=3 rax=0
x=1 y=0 rax=0
x=1 y=1 rax=0
x=1 y=2 rax=0
x=1 y=3 rax=0
x=2 y=0 rax=4
x=2 y=1 rax=4
x=2 y=2 rax=4
x=2 y=3 rax=4
x=3 y=0 rax=0
x=3 y=1 rax=0
x=3 y=2 rax=0
x=3 y=3 rax=0

可知并不是所有不大于14的$x$都满足条件；使func4(x, 0, 14)返回0的$x$为二分搜索路径全向左的节点，例如$x=0,1,3,7$，同时$y$必须取0

如取 0 0 即可

phase_5

 0000000000401062 <phase_5>: 
  401062:	53                   	push   %rbx
  401063:	48 83 ec 20          	sub    $0x20,%rsp
  401067:	48 89 fb             	mov    %rdi,%rbx
  40106a:	64 48 8b 04 25 28 00 	mov    %fs:0x28,%rax
  401071:	00 00 
  401073:	48 89 44 24 18       	mov    %rax,0x18(%rsp)
  401078:	31 c0                	xor    %eax,%eax
  40107a:	e8 9c 02 00 00       	call   40131b <string_length>
  40107f:	83 f8 06             	cmp    $0x6,%eax
  401082:	74 4e                	je     4010d2 <phase_5+0x70>
  401084:	e8 b1 03 00 00       	call   40143a <explode_bomb>
  401089:	eb 47                	jmp    4010d2 <phase_5+0x70>
  40108b:	0f b6 0c 03          	movzbl (%rbx,%rax,1),%ecx
  40108f:	88 0c 24             	mov    %cl,(%rsp)
  401092:	48 8b 14 24          	mov    (%rsp),%rdx
  401096:	83 e2 0f             	and    $0xf,%edx
  401099:	0f b6 92 b0 24 40 00 	movzbl 0x4024b0(%rdx),%edx
  4010a0:	88 54 04 10          	mov    %dl,0x10(%rsp,%rax,1)
  4010a4:	48 83 c0 01          	add    $0x1,%rax
  4010a8:	48 83 f8 06          	cmp    $0x6,%rax
  4010ac:	75 dd                	jne    40108b <phase_5+0x29>
  4010ae:	c6 44 24 16 00       	movb   $0x0,0x16(%rsp)
  4010b3:	be 5e 24 40 00       	mov    $0x40245e,%esi
  4010b8:	48 8d 7c 24 10       	lea    0x10(%rsp),%rdi
  4010bd:	e8 76 02 00 00       	call   401338 <strings_not_equal>
  4010c2:	85 c0                	test   %eax,%eax
  4010c4:	74 13                	je     4010d9 <phase_5+0x77>
  4010c6:	e8 6f 03 00 00       	call   40143a <explode_bomb>
  4010cb:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)
  4010d0:	eb 07                	jmp    4010d9 <phase_5+0x77>
  4010d2:	b8 00 00 00 00       	mov    $0x0,%eax
  4010d7:	eb b2                	jmp    40108b <phase_5+0x29>
  4010d9:	48 8b 44 24 18       	mov    0x18(%rsp),%rax
  4010de:	64 48 33 04 25 28 00 	xor    %fs:0x28,%rax
  4010e5:	00 00 
  4010e7:	74 05                	je     4010ee <phase_5+0x8c>
  4010e9:	e8 42 fa ff ff       	call   400b30 <__stack_chk_fail@plt>
  4010ee:	48 83 c4 20          	add    $0x20,%rsp
  4010f2:	5b                   	pop    %rbx
  4010f3:	c3                   	ret

可以发现读入的是一个字符串，在其长度不为6的时候爆炸

否则将$%rax$设置为0，$%rbx$指向读入字符串的首地址，通过movzbl (%rbx,%rax,1),%ecx访问字符串的第一个字符，将其$and$上15，即取其ASCII码的后四位得到一个整数$k$，以movzbl 0x4024b0(%rdx),%edx访问0x4024b0的后面第$k$个字符并将其最终放入0x10(%rsp,%rax,1)中，重复以上流程六次，然后将地址为$0x40245e$的字符串放入$%esi$中,$%rdi$指向$0x10(%rsp)$即转换后的字符串，将这两个字符串进行比较，若不相等则会爆炸

通过 (gdb) x/s 0x4024b0，我们得到这个地址后面的字符串为 maduiersnfotvbylSo you think you can stop the bomb with ctrl-c, do you?

通过 (gdb) x/s 0x40245e可以得到目标字符串为 0x40245e: "flyers"

所以我们只需要输入的每个字符的$ASCII$码二进制后4位转换为十进制分别为9,15,14,5,6,7 就行了

查$ASCII$表发现 Y_.UFG为一组可能的解

phase_6

 00000000004010f4 <phase_6>:
  4010f4:	41 56                	push   %r14
  4010f6:	41 55                	push   %r13
  4010f8:	41 54                	push   %r12
  4010fa:	55                   	push   %rbp
  4010fb:	53                   	push   %rbx
  4010fc:	48 83 ec 50          	sub    $0x50,%rsp
  401100:	49 89 e5             	mov    %rsp,%r13
  401103:	48 89 e6             	mov    %rsp,%rsi
  401106:	e8 51 03 00 00       	call   40145c <read_six_numbers>
  40110b:	49 89 e6             	mov    %rsp,%r14
  40110e:	41 bc 00 00 00 00    	mov    $0x0,%r12d
  401114:	4c 89 ed             	mov    %r13,%rbp
  401117:	41 8b 45 00          	mov    0x0(%r13),%eax
  40111b:	83 e8 01             	sub    $0x1,%eax
  40111e:	83 f8 05             	cmp    $0x5,%eax
  401121:	76 05                	jbe    401128 <phase_6+0x34>
  401123:	e8 12 03 00 00       	call   40143a <explode_bomb>
  401128:	41 83 c4 01          	add    $0x1,%r12d
  40112c:	41 83 fc 06          	cmp    $0x6,%r12d
  401130:	74 21                	je     401153 <phase_6+0x5f>
  401132:	44 89 e3             	mov    %r12d,%ebx
  401135:	48 63 c3             	movslq %ebx,%rax
  401138:	8b 04 84             	mov    (%rsp,%rax,4),%eax
  40113b:	39 45 00             	cmp    %eax,0x0(%rbp)
  40113e:	75 05                	jne    401145 <phase_6+0x51>
  401140:	e8 f5 02 00 00       	call   40143a <explode_bomb>
  401145:	83 c3 01             	add    $0x1,%ebx
  401148:	83 fb 05             	cmp    $0x5,%ebx
  40114b:	7e e8                	jle    401135 <phase_6+0x41>
  40114d:	49 83 c5 04          	add    $0x4,%r13
  401151:	eb c1                	jmp    401114 <phase_6+0x20>
  401153:	

设进入函数时$%rsp$指向的地址为$p$，由$phase_2$的分析可知，读入的六个数(设为$a_0$,$a_1$,$a_2$,$a_3$,$a_4$,$a_5$)地址依次分别在$p-80$，$p-76$，$p-72$，$p-68$，$p-64$，$p-60$

此后，$%rbp$指向了第一个数的地址，检查了这个位置的值，大于6时会爆炸，然后$%rbx$从$%r12$的值开始(初始$%r12$为1)一直到6，检查第$%rbx$个数是否与$%rbp$相等，相等则会爆炸

此后，将$%rbp$指向下一个数，$%r12$的值增加1，重复上一个步骤，直到$%r12$的值等于6，即$%rbp$之后没有其他数

所以当这六个数都在1到6之间且互不相等的时候不会爆炸

手动模拟发现，执行完上述指令后$%rsp$,$%r14$,$%r12$,$%r13$,$%rbp$,$%rax$,$%rbx$的值分别是$p-80$,$p-80$,$6$,$p-60$,$p-60$,$a_6$,$6$

  401153:	48 8d 74 24 18       	lea    0x18(%rsp),%rsi
  401158:	4c 89 f0             	mov    %r14,%rax
  40115b:	b9 07 00 00 00       	mov    $0x7,%ecx
  401160:	89 ca                	mov    %ecx,%edx
  401162:	2b 10                	sub    (%rax),%edx
  401164:	89 10                	mov    %edx,(%rax)
  401166:	48 83 c0 04          	add    $0x4,%rax
  40116a:	48 39 f0             	cmp    %rsi,%rax
  40116d:	75 f1                	jne    401160 <phase_6+0x6c>

这段指令以$%rax$为指针，从第一个数开始直到最后一个数，将每个数$a_i$都赋值为$7-a_i$，我们不妨设$b_i = 7 - a_i$

  40116f:	be 00 00 00 00       	mov    $0x0,%esi
  401174:	eb 21                	jmp    401197 <phase_6+0xa3>
  401176:	48 8b 52 08          	mov    0x8(%rdx),%rdx
  40117a:	83 c0 01             	add    $0x1,%eax
  40117d:	39 c8                	cmp    %ecx,%eax
  40117f:	75 f5                	jne    401176 <phase_6+0x82>
  401181:	eb 05                	jmp    401188 <phase_6+0x94>
  401183:	ba d0 32 60 00       	mov    $0x6032d0,%edx
  401188:	48 89 54 74 20       	mov    %rdx,0x20(%rsp,%rsi,2)
  40118d:	48 83 c6 04          	add    $0x4,%rsi
  401191:	48 83 fe 18          	cmp    $0x18,%rsi
  401195:	74 14                	je     4011ab <phase_6+0xb7>
  401197:	8b 0c 34             	mov    (%rsp,%rsi,1),%ecx
  40119a:	83 f9 01             	cmp    $0x1,%ecx
  40119d:	7e e4                	jle    401183 <phase_6+0x8f>
  40119f:	b8 01 00 00 00       	mov    $0x1,%eax
  4011a4:	ba d0 32 60 00       	mov    $0x6032d0,%edx
  4011a9:	eb cb                	jmp    401176 <phase_6+0x82>

看不懂，这家伙又在叽里咕噜说些什么呢（

注意到有一个常量地址 $0x6032d0，于是我们使用 (gdb) x/x 0x6032d0 ，发现输出结果为 0x6032d0 <node1>: 0x0000014c

这个变量名$node1$有点意思，进一步地，我们使用 (gdb) x/16x 0x6032d0 可以发现输出的结果为

我们发现，除了$node_6$每个$node_i$的第三个变量都是$node_{i+1}$的地址，可以联想到链表

同时发现每个节点占用4个单位，可以推测是一个64位的指针和两个32位的$int$变量

由于$x86$使用小端法，不难想到节点结构体应该是这样定义的

struct node {
	int val, key;
    node * nxt;
}nd[7];

链表的结构如下图

接下来我们按汇编代码手玩发现，首先通过$%rcx$指向第$i$个数的地址($i$从0取到5)

如果$b_i$的值为1(即$a_i=6$)，就直接将$0x6032d0$（链表的首地址）放入地址为$p-48+8*i$的内存中

否则将$%rdx$指向链表的首地址，并每次移动到$%rbx+8$这个地址(链表下一个节点的地址)，即 $rbx = rbx -> nxt$，直到当前指向的是链表中第$b_i$个节点，然后将当前的地址放入地址为$p-48+8i$的内存中

重复以上过程，直到6个节点地址都被保存下来

我们设重排后的节点从地址$p-48$开始，分别保存的信息为三元组$(val_i,id_i,nxt_i)$

  4011ab:	48 8b 5c 24 20       	mov    0x20(%rsp),%rbx
  4011b0:	48 8d 44 24 28       	lea    0x28(%rsp),%rax
  4011b5:	48 8d 74 24 50       	lea    0x50(%rsp),%rsi
  4011ba:	48 89 d9             	mov    %rbx,%rcx
  4011bd:	48 8b 10             	mov    (%rax),%rdx
  4011c0:	48 89 51 08          	mov    %rdx,0x8(%rcx)
  4011c4:	48 83 c0 08          	add    $0x8,%rax
  4011c8:	48 39 f0             	cmp    %rsi,%rax
  4011cb:	74 05                	je     4011d2 <phase_6+0xde>
  4011cd:	48 89 d1             	mov    %rdx,%rcx
  4011d0:	eb eb                	jmp    4011bd <phase_6+0xc9>
  4011d2:	48 c7 42 08 00 00 00 	movq   $0x0,0x8(%rdx)

接下来这段汇编代码从重排后的链表第一个节点开始，将$nxt_i$地址指针改为了重排后下一个节点的地址，最后一个节点的$nxt$地址指针被设置为了$0$($NULL$)

  4011d9:	00 
  4011da:	bd 05 00 00 00       	mov    $0x5,%ebp
  4011df:	48 8b 43 08          	mov    0x8(%rbx),%rax
  4011e3:	8b 00                	mov    (%rax),%eax
  4011e5:	39 03                	cmp    %eax,(%rbx)
  4011e7:	7d 05                	jge    4011ee <phase_6+0xfa>
  4011e9:	e8 4c 02 00 00       	call   40143a <explode_bomb>
  4011ee:	48 8b 5b 08          	mov    0x8(%rbx),%rbx
  4011f2:	83 ed 01             	sub    $0x1,%ebp
  4011f5:	75 e8                	jne    4011df <phase_6+0xeb>
  4011f7:	48 83 c4 50          	add    $0x50,%rsp
  4011fb:	5b                   	pop    %rbx
  4011fc:	5d                   	pop    %rbp
  4011fd:	41 5c                	pop    %r12
  4011ff:	41 5d                	pop    %r13
  401201:	41 5e                	pop    %r14
  401203:	c3                   	ret

此后对于重排后的前5个节点，用$%rbx$指向它，用$%rax$指向它的下一个节点，将它们指向的值进行比较(注意比较时使用的是$%eax$，即使用前32位的$val$值进行比较)，当前一个值小于下一个值的时候发生爆炸，否则整个函数安全退出

所以我们的目标很明确了，只需要使得输入能将链表的$val$值从大到小排序就行了

可以得到链表的顺序按照$id$排序应该为 3 4 5 6 1 2，这就是$b$数组

注意输入的$b_i=7-a_i$，所以输入的$a$数组应该为 4 3 2 1 6 5

结果

完结撒花！

Part A

写在前面

这部分要求你实现一个模拟缓存运行的C语言程序，支持读，写，修改内存三个操作，其与对于缓存模拟的行为给定的$csim-ref$可执行文件一致，最后输出操作完成后的缓存命中，未命中，替换的次数。缓存的组数，行数，每一行的字节数在执行时以参数给出，替换策略使用$LRU$(least-recently used)，即每次替换块内离上一次引用时间最久的块

但是本部分不要求你输出访问时具体的值，你只需要统计这次操作是否命中，未命中，替换

在运行的时候，我们采用了一下的选项来传递参数

linux> ./csim-ref [-hv] -s <s> -E <E> -b <b>-t <tracefile>

其中-h -v两个选项可选可不选，且后面没有参数，分别表示打印使用方法，和运行时是否可见化地输出每次缓存访问的结果

-s -E -b 后接一个参数，分别表示组索引位数、每组行数、块偏移位数；因此组数$S=2^s$，块大小$B=2^b$

-t 后接字符串参数，表示读入文件的路径

读入部分

怎么感觉是Part A 里面最难的部分（

首先为了从选项中读出参数，我们在linux系统下需要使用$getopt$函数，该函数原型如下

int getopt(int argc, char * const argv[], const char *optstring)

其中$argc$，$argv$为$main$函数的参数，分别代表参数个数和参数列表

$optstring$为选项字符串，举例来说，getopt(argc, argv, "hvs:E:b:t:")就表示有-h -v -s -E -b -t 这几个选项，其中-s -E -b -t 若选择的话，后面必须带有参数

该函数返回值为选项的ASCII码，同时，包含该函数的 <unistd.h> 和 <getopt.h> 中有名为 $optarg$的指针变量，在每次使用$getopt$时，若该选项有参数，就会被更新为该参数的字符串指针

由此不难写出读入函数

    int op;
    FILE *fp;

    while ((op = getopt(argc, argv, "hvs:E:b:t:")) != EOF) {
        if (op == 'h') {
            Help();
            return 0;
        }
        if (op == 'v') {
            v = 1;
            continue;
        }
        if (op == 's') {
            s = atoi(optarg);//atoi 在 stdlib.h中，传入一个字符串开头的指针，将其转换为整数
            S = (1 << s);
            continue;
        }
        if (op == 'E') {
            E = atoi(optarg);
            continue;
        }
        if (op == 'b') {
            b = atoi(optarg);
            B = (1 << b);
            continue;
        }
        if (op == 't') {
            fp = fopen(optarg, "r");//文件指针指向参数标明的文件
            continue;
        }
        Help();
        return 0;//其它异常参数符
    }

每次操作分为以下四类：

1. I address,size表示取address地址开始的size字节指令
2. L address,size 表示加载address地址开始的size字节数据
3. S address,size 表示向address地址开始的size字节写数据
4. M address,size 表示修改address地址开始的size字节数据

但是这部分只要我们用缓存处理数据信息，同时又不需要真正地对缓存进行读写，只是模拟是否命中和替换这个过程即可

所以 I操作完全没用， L 和S操作完全等价 （无语

    char opt[5];
    size_t ad;
    int siz;
    while (fscanf(fp, "%s %lx,%d", opt, &ad, &siz) != EOF) {
        ++curtime;
        if (v) {
            printf("%c %lx,%d\n", opt[0], ad, siz);
        }
        if (opt[0] == 'I') continue;
        if (opt[0] == 'L') Load(ad);
        if (opt[0] == 'S') Store(ad);
        if (opt[0] == 'M') Modify(ad);
    }

缓存的相关结构

由于本部分缓存大小未知，需要动态分配内存，这里实现上使用了指针加 malloc动态分配空间

struct row {
    int valid, flag, dfn;
    //有效位 标志位 上次更新的时间戳
};//一行

typedef struct row* set;//一组
typedef set* cache;//整个缓存
cache c;

void Cache_init() {
    c = (cache)malloc(sizeof(set) * S);//分配S个组的空间
    for (int i = 0; i < S; i++) {
        c[i] = (set)malloc(sizeof(struct row) * E);//每一组分配E行的空间
        for (int j = 0; j < E; j++) {
            c[i][j].valid = 0;
            c[i][j].flag = c[i][j].dfn = -1;
        }
    }
}

缓存的读写

我们先对地址使用位运算得到该地址应该被分配到的组数，标识位和偏移量（偏移量好像没用）

为了维护某一组内是否有该地址对应的标志位，我们可以采用平衡树，但是E一般都比较小，没有这个必要（不是我懒得写了），直接E行依遍历比较就行

如果存在标识符相同且有效的，那么发生缓存命中，修改这一行的时间戳，直接返回即可

否则缓存未命中，我们优先找该组空的行，若存在，直接放入并更新时间戳，将其有效位设置为1，此时未命中，也未发生替换

如空的行不存在，我们就将该组中时间戳最小的行替换为需要访问的数据，同样更新时间戳即可，此时未命中并发生替换

void Load(int ad) {
    //m = t + s + b
    // int _b = ad & ((1 << b) - 1);
    int _s = (ad >> b) & ((1 << s) - 1);
    int _t = ad >> (s + b);

    struct row* r = c[_s];
    for (int i = 0; i < E; i++) {
        if ((r + i)->valid && (r + i)->flag == _t) {//缓存命中
            if (v) puts("hit");
            ++hit;
            (r + i)->dfn = curtime;
            return;
        }
    }
    

    struct row* evicp = r;
    for (int i = 1; i < E; i++) {
        if ((r + i)->dfn == -1 || (r + i)->dfn < evicp->dfn) {//优先使用空行
            evicp = r + i;
        }
    }
    
    miss++; 
    printf("miss");
    if (evicp->dfn != -1) {
        evic++;
        if (v) printf(" eviction");
    }//发生了替换
    putchar('\n');
    evicp->dfn = curtime; evicp->valid = 1; evicp -> flag = _t;
    return;
}

写入和加载的缓存行为在本模拟器中完全一致。修改操作M等价于一次加载后紧跟一次存储：如果第一次访问未命中，则会统计一次未命中并把块载入缓存，随后第二次存储必然命中；如果第一次访问命中，则总共统计两次命中

void Store(int ad) {
    Load(ad);
}

void Modify(int ad) {
    //m = t + s + b
    // int _b = ad & ((1 << b) - 1);
    int _s = (ad >> b) & ((1 << s) - 1);
    int _t = ad >> (s + b);
    struct row *r = c[_s]; 
    for (int i = 0; i < E; i++) {
        if ((r + i)->valid && (r + i)->flag == _t) {
            if (v) puts("hit");
            hit += 2;
            (r + i)->dfn = curtime;
            return;
        }
    }

    struct row* evicp = r;
    for (int i = 1; i < E; i++) {
        if ((r + i)->dfn == -1 || (r + i)->dfn < evicp->dfn) {
            evicp = r + i;
        }
    }
    
    miss++;  hit++;
    if (v) puts("miss");
    if (evicp->dfn != -1) {
        evic++;
        if (v) printf(" eviction");
    }
    puts(" hit");
    evicp->dfn = curtime; evicp->valid = 1; evicp -> flag = _t;
    return;
}

​

代码

主体已经完成了，再加上使用说明即可

#include "cachelab.h"
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>

int E, s, S, b, B, v, t;
const int m = 64;
int curtime;
int hit, miss, evic;

struct row {
    int valid, flag, dfn;
    //有效位 标志位 上次更新的时间戳
};//一行

typedef struct row* set;//一组
typedef set* cache;//整个缓存
cache c;

void Cache_init() {
    c = (cache)malloc(sizeof(set) * S);//分配S个组的空间
    for (int i = 0; i < S; i++) {
        c[i] = (set)malloc(sizeof(struct row) * E);//每一组分配E行的空间
        for (int j = 0; j < E; j++) {
            c[i][j].valid = 0;
            c[i][j].flag = c[i][j].dfn = -1;
        }
    }
}

/*
Usage: ./csim-ref [-hv] -s <num> -E <num> -b <num> -t <file>
Options:
  -h         Print this help message.
  -v         Optional verbose flag.
  -s <num>   Number of set index bits.
  -E <num>   Number of lines per set.
  -b <num>   Number of block offset bits.
  -t <file>  Trace file.

Examples:
  linux>  ./csim-ref -s 4 -E 1 -b 4 -t traces/yi.trace
  linux>  ./csim-ref -v -s 8 -E 2 -b 4 -t traces/yi.trace
*/

void Help() {
    printf(
"Usage: ./csim-ref [-hv] -s <num> -E <num> -b <num> -t <file>\n"
"Options:\n"
"  -h         Print this help message.\n"
"  -v         Optional verbose flag.\n"
"  -s <num>   Number of set index bits.\n"
"  -E <num>   Number of lines per set.\n"
"  -b <num>   Number of block offset bits.\n"
"  -t <file>  Trace file.\n"

"Examples:\n"
"  linux>  ./csim-ref -s 4 -E 1 -b 4 -t traces/yi.trace\n"
"  linux>  ./csim-ref -v -s 8 -E 2 -b 4 -t traces/yi.trace\n"
    );
}

void Load(int ad) {
    //m = t + s + b
    // int _b = ad & ((1 << b) - 1);
    int _s = (ad >> b) & ((1 << s) - 1);
    int _t = ad >> (s + b);

    struct row* r = c[_s];
    for (int i = 0; i < E; i++) {
        if ((r + i)->valid && (r + i)->flag == _t) {//缓存命中
            if (v) puts("hit");
            ++hit;
            (r + i)->dfn = curtime;
            return;
        }
    }
    

    struct row* evicp = r;
    for (int i = 1; i < E; i++) {
        if ((r + i)->dfn == -1 || (r + i)->dfn < evicp->dfn) {//优先使用空行
            evicp = r + i;
        }
    }
    
    miss++; 
    printf("miss");
    if (evicp->dfn != -1) {
        evic++;
        if (v) printf(" eviction");
    }//发生了替换
    putchar('\n');
    evicp->dfn = curtime; evicp->valid = 1; evicp -> flag = _t;
    return;
}

void Store(int ad) {
    Load(ad);
}

void Modify(int ad) {
    //m = t + s + b
    // int _b = ad & ((1 << b) - 1);
    int _s = (ad >> b) & ((1 << s) - 1);
    int _t = ad >> (s + b);
    struct row *r = c[_s]; 
    for (int i = 0; i < E; i++) {
        if ((r + i)->valid && (r + i)->flag == _t) {
            if (v) puts("hit");
            hit += 2;
            (r + i)->dfn = curtime;
            return;
        }
    }

    struct row* evicp = r;
    for (int i = 1; i < E; i++) {
        if ((r + i)->dfn == -1 || (r + i)->dfn < evicp->dfn) {
            evicp = r + i;
        }
    }
    
    miss++;  hit++;
    if (v) puts("miss");
    if (evicp->dfn != -1) {
        evic++;
        if (v) printf(" eviction");
    }
    puts(" hit");
    evicp->dfn = curtime; evicp->valid = 1; evicp -> flag = _t;
    return;
}


int main(int argc, char *argv[]){
    int op;
    FILE *fp;

    while ((op = getopt(argc, argv, "hvs:E:b:t:")) != EOF) {
        if (op == 'h') {
            Help();
            return 0;
        }
        if (op == 'v') {
            v = 1;
            continue;
        }
        if (op == 's') {
            s = atoi(optarg);//atoi 在 stdlib.h中，传入一个字符串开头的指针，将其转换为整数
            S = (1 << s);
            continue;
        }
        if (op == 'E') {
            E = atoi(optarg);
            continue;
        }
        if (op == 'b') {
            b = atoi(optarg);
            B = (1 << b);
            continue;
        }
        if (op == 't') {
            fp = fopen(optarg, "r");//文件指针指向参数标明的文件
            continue;
        }
        Help();
        return 0;//其它异常参数符
    }

    Cache_init();//缓冲初始化，动态分配空间

    char opt[5];
    size_t ad;
    int siz;
    while (fscanf(fp, "%s %lx,%d", opt, &ad, &siz) != EOF) {
        ++curtime;
        if (v) {
            printf("%c %lx,%d\n", opt[0], ad, siz);
        }
        if (opt[0] == 'I') continue;
        if (opt[0] == 'L') Load(ad);
        if (opt[0] == 'S') Store(ad);
        if (opt[0] == 'M') Modify(ad);
    }

    printSummary(hit, miss, evic);
    return 0;
}

使用 make && ./test-csim得到以下结果

Part B

写在前面

有$32 \times 32$， $64 \times 64$， $61 \times 67$ 三个矩阵$A$，你需要使用C实现矩阵转置得到矩阵$B$，要求使得参数为$(s=5, E=1, b=5)$的缓存产生的不命中次数小于一个给定值，不能自己定义数组，最多使用12个局部变量

手算发现，该缓存有32个组，每组一行，块大小为32字节，即每块能存储8个int。方便起见，以下把一个缓存块称为一行，同时使用0-index

通过访问目录下的$trace.f1$(题目给出的不加优化的转置代码的缓存行为跟踪)发现，$A$的起始地址为$0x0010d080$，$B$的起始地址为$0x0014d080$，刚好相差$2^{18}$，这说明在下标相同时，$A[i][j]$和$B[i][j]$会被分配到相同的一行内，只是标志位不同；同时二者的起始地址都是32的倍数，说明$A[i][8k+0]$到$A[i][8k+7]$都在一行里面，$B$也同理

题目给出的最原始的转置函数如下

void trans(int M, int N, int A[N][M], int B[M][N])
{
    int i, j, tmp;

    for (i = 0; i < N; i++) {
        for (j = 0; j < M; j++) {
            tmp = A[i][j];
            B[j][i] = tmp;
        }
    }    
}

注意先通过 sudo apt install valgrind 安装 valgrind

$ 32 \times 32 $

本部分要求缓存未命中次数小于300次

先在目录下使用make && ./test-trans -M 32 -N 32对原始函数缓存访问效率进行测试，结果如下

发现该函数对于缓存访问相当不友好，我们先搞明白1183次不命中是怎么来的

每隔8个int就会产生一个行的偏移，先画出每个int会被放入缓存的哪一行（不会画图，图是偷的，勿喷）

1.对于$A$是步长为1的访问，只有在第一次访问一个没有被访问过的组的时候才会不命中，所以会有128次不命中

2.对于$B$是步长为32的访问，每一次都不会命中，所以有1024次不命中

3.对于 $i=j$ 即对角线上的情况，此时$B[i][i]$和$A[i][i]$所在的组一样，写入$B[i][i]$的值的时候，刚好会将$A$所在行替换掉，在下一次读取$A$的值的时候，会将$B$替换掉，这样的情况会发生31次，因为最后一次访问$(31,31)$后不会再读取$A$了

所以一共为128+1024+31=1183次

接下来考虑如何优化，可以使用分块，取块长为8，即每次将一个$8\times8$的$A$矩阵写入其在$B$上对应的位置

这样优化后，$A$在块内以步长为1访问，而$B$在块内按列顺序访问，每一块会在每一列第一次访问的时候不命中

优化后代码如下

    if (M == 32 && N == 32) {
        for (i = 0; i < N; i += 8) {
            for (j = 0; j < M; j += 8) {
                for (ii = i; ii < i + 8; ii++) {
                    for (jj = j; jj < j + 8; jj++) {
                        B[jj][ii] = A[ii][jj];
                    }
                }
            }
        }
    }

仍然需要进一步的优化，考虑对角线上的块，在转置的时候会发生对$B$进行写入时，替换掉了这一行的$A$，所以可以使用临时变量保存$A$的值，然后放入$B$中，这样减少了访问$A$这一行后面的元素所需要的一次不命中

    if (M == 32 && N == 32) {
        for (i = 0; i < N; i += 8) {
            for (j = 0; j < M; j += 8) {
                for (ii = i; ii < i + 8; ii++) {
                    a = A[ii][j];
                    b = A[ii][j + 1];
                    c = A[ii][j + 2];
                    d = A[ii][j + 3];
                    e = A[ii][j + 4];
                    f = A[ii][j + 5];
                    g = A[ii][j + 6];
                    h = A[ii][j + 7];
                    B[j ][ii] = a;
                    B[j + 1][ii] = b;
                    B[j + 2][ii] = c;
                    B[j + 3][ii] = d;
                    B[j + 4][ii] = e;
                    B[j + 5][ii] = f;
                    B[j + 6][ii] = g;
                    B[j + 7][ii] = h;
                }
            }
        }
    }

结果如下，成功通过此题

$64\times64$

本部分要求缓存未命中次数小于1300

再次偷图（ 这是左上角$16 \times 16$的矩阵

如果我们仍然采用$8\times8$分块处理的话，块内会存在严重的抖动，比如$B$内部对组0，组8，组16，组24都有两次访问，都会产生一次替换，这导致缓存命中率相当糟糕，实际测试中不命中次数为4611，与未优化的原始代码次数4723几乎没有差别

为了减少$B$的抖动，我们尝试使用$4\times4$分块

    if (M == 64 && N == 64) {
        for (i = 0; i < N; i += 4) {
            for (j = 0; j < M; j += 4) {
                for (ii = i; ii < i + 4; ii++) {                                     
                    a = A[ii][j];
                    b = A[ii][j + 1];
                    c = A[ii][j + 2];
                    d = A[ii][j + 3];
                    B[j ][ii] = a;
                    B[j + 1][ii] = b;
                    B[j + 2][ii] = c;
                    B[j + 3][ii] = d;
                }
            }
        }    
    }

结果如下

有所优化但是还未达到本题要求，采用$4\times4$分块的时候，虽然$B$的抖动减少了，但是对$A$中原本连续8个数的访问变成了两次对4个数的访问，这增加了$A$的抖动

到这里就不会了，去看别人博客了（

我们考虑以下的策略

1.先读取$A$矩阵$8\times8$分块的前4行，将黄色部分和绿色部分分别转置后，直接顺序不变拷贝到$B$中，此时未发生缓存替换，只有$A$和$B$的各4次载入

2.使用寄存器暂存未放置正确的绿色部分的一行，然后将粉色部分的一列放置到绿色部分的这一行，接着从寄存器中取值将绿色部分这一行放到正确的位置。绿色部分已经存放在了缓存中，可以直接读取，粉色第一列的时候会发生4次载入，热身缓存，正确放置绿色部分每一行的时候都会产生一次对原本存放$A$的组的替换，故一共发生8次缓存不命中

3.最后将紫色部分直接转置到正确位置即可，紫色部分每一行和放置的$B$每一列都在缓存中，全部命中

所以对于$8\times8$的块，发生了16次不命中，对$64 \times 64$的块，理论会有1024次不命中

    if (M == 64 && N == 64) {
        int i, j, ii;
        int a, b, c, d, e, f, g, h;

        for (i = 0; i < N; i += 8) {
            for (j = 0; j < M; j += 8) {
                for (ii = i; ii < i + 4; ii++) {
                    a = A[ii][j];
                    b = A[ii][j + 1];
                    c = A[ii][j + 2];
                    d = A[ii][j + 3];

                    e = A[ii][j + 4];
                    f = A[ii][j + 5];
                    g = A[ii][j + 6];
                    h = A[ii][j + 7];

                    B[j][ii] = a;
                    B[j + 1][ii] = b;
                    B[j + 2][ii] = c;
                    B[j + 3][ii] = d;
                    
                    B[j][ii + 4] = e;
                    B[j + 1][ii + 4] = f;
                    B[j + 2][ii + 4] = g;
                    B[j + 3][ii + 4] = h;
                }

                for (ii = 0; ii < 4; ii++) {
                    a = B[j + ii][i + 4]; 
                    b = B[j + ii][i + 5];
                    c = B[j + ii][i + 6];
                    d = B[j + ii][i + 7];

                    e = A[i + 4][j + ii];
                    f = A[i + 5][j + ii];
                    g = A[i + 6][j + ii];
                    h = A[i + 7][j + ii];

                    B[j + ii][i + 4] = e;
                    B[j + ii][i + 5] = f;
                    B[j + ii][i + 6] = g;
                    B[j + ii][i + 7] = h;

                    B[j + 4 + ii][i] = a;
                    B[j + 4 + ii][i + 1] = b;
                    B[j + 4 + ii][i + 2] = c;
                    B[j + 4 + ii][i + 3] = d;
                }


                for (ii = i + 4; ii < i + 8; ii++) {
                    a = A[ii][j + 4];
                    b = A[ii][j + 5];
                    c = A[ii][j + 6];
                    d = A[ii][j + 7];

                    B[j + 4][ii] = a;
                    B[j + 5][ii] = b;
                    B[j + 6][ii] = c;
                    B[j + 7][ii] = d;
                }
            }
        }    
        return;
    }

运行结果如下，达到了本题的要求

$67 \times 61$

本题要求缓存不命中次数小于2000

我们调整参数，发现使用$16 \times 16$分块可以通过此题

    if (M == 67 && N == 61) {
        int i, j, ii,jj;
        for (i = 0; i < 61; i += 16) {
            for (j = 0; j < 67; j += 16) {
                for (ii = i; ii < i + 16 && ii < 61; ii++) {
                    for (jj = j; jj < j + 16 && jj < 67; jj++) {
                        B[jj][ii] = A[ii][jj];
                    }
                }
            }
        }
    }

结果如下

代码

/* 
 * trans.c - Matrix transpose B = A^T
 *
 * Each transpose function must have a prototype of the form:
 * void trans(int M, int N, int A[N][M], int B[M][N]);
 *
 * A transpose function is evaluated by counting the number of misses
 * on a 1KB direct mapped cache with a block size of 32 bytes.
 */ 
#include <stdio.h>
#include "cachelab.h"

int is_transpose(int M, int N, int A[N][M], int B[M][N]);

/* 
 * transpose_submit - This is the solution transpose function that you
 *     will be graded on for Part B of the assignment. Do not change
 *     the description string "Transpose submission", as the driver
 *     searches for that string to identify the transpose function to
 *     be graded. 
 */
char transpose_submit_desc[] = "Transpose submission";
void transpose_submit(int M, int N, int A[N][M], int B[M][N])
{

    if (M == 32 && N == 32) {
        int i, j, ii;
        int a, b, c, d, e, f, g, h;
        for (i = 0; i < N; i += 8) {
            for (j = 0; j < M; j += 8) {
                for (ii = i; ii < i + 8; ii++) {
                    a = A[ii][j];
                    b = A[ii][j + 1];
                    c = A[ii][j + 2];
                    d = A[ii][j + 3];
                    e = A[ii][j + 4];
                    f = A[ii][j + 5];
                    g = A[ii][j + 6];
                    h = A[ii][j + 7];
                    B[j ][ii] = a;
                    B[j + 1][ii] = b;
                    B[j + 2][ii] = c;
                    B[j + 3][ii] = d;
                    B[j + 4][ii] = e;
                    B[j + 5][ii] = f;
                    B[j + 6][ii] = g;
                    B[j + 7][ii] = h;
                }
            }
        }
        return;
    }

    if (M == 64 && N == 64) {
        int i, j, ii;
        int a, b, c, d, e, f, g, h;

        for (i = 0; i < N; i += 8) {
            for (j = 0; j < M; j += 8) {
                for (ii = i; ii < i + 4; ii++) {
                    a = A[ii][j];
                    b = A[ii][j + 1];
                    c = A[ii][j + 2];
                    d = A[ii][j + 3];

                    e = A[ii][j + 4];
                    f = A[ii][j + 5];
                    g = A[ii][j + 6];
                    h = A[ii][j + 7];

                    B[j][ii] = a;
                    B[j + 1][ii] = b;
                    B[j + 2][ii] = c;
                    B[j + 3][ii] = d;
                    
                    B[j][ii + 4] = e;
                    B[j + 1][ii + 4] = f;
                    B[j + 2][ii + 4] = g;
                    B[j + 3][ii + 4] = h;
                }

                for (ii = 0; ii < 4; ii++) {
                    a = B[j + ii][i + 4]; 
                    b = B[j + ii][i + 5];
                    c = B[j + ii][i + 6];
                    d = B[j + ii][i + 7];

                    e = A[i + 4][j + ii];
                    f = A[i + 5][j + ii];
                    g = A[i + 6][j + ii];
                    h = A[i + 7][j + ii];

                    B[j + ii][i + 4] = e;
                    B[j + ii][i + 5] = f;
                    B[j + ii][i + 6] = g;
                    B[j + ii][i + 7] = h;

                    B[j + 4 + ii][i] = a;
                    B[j + 4 + ii][i + 1] = b;
                    B[j + 4 + ii][i + 2] = c;
                    B[j + 4 + ii][i + 3] = d;
                }


                for (ii = i + 4; ii < i + 8; ii++) {
                    a = A[ii][j + 4];
                    b = A[ii][j + 5];
                    c = A[ii][j + 6];
                    d = A[ii][j + 7];

                    B[j + 4][ii] = a;
                    B[j + 5][ii] = b;
                    B[j + 6][ii] = c;
                    B[j + 7][ii] = d;
                }
            }
        }    
        return;
    }

    if (M == 61 && N == 67) {
        int i, j, ii,jj, tmp;
        for (i = 0; i < N; i += 16) {
            for (j = 0; j < M; j += 16) {
                for (ii = i; ii < i + 16 && ii < N; ii++) {
                    for (jj = j; jj < j + 16 && jj < M; jj++) {
                        tmp = A[ii][jj];
                        B[jj][ii] = tmp;
                    }
                }
            }
        }
    }
}

/* 
 * You can define additional transpose functions below. We've defined
 * a simple one below to help you get started. 
 */ 

/* 
 * trans - A simple baseline transpose function, not optimized for the cache.
 */
char trans_desc[] = "Simple row-wise scan transpose";
void trans(int M, int N, int A[N][M], int B[M][N])
{
    int i, j, tmp;

    for (i = 0; i < N; i++) {
        for (j = 0; j < M; j++) {
            tmp = A[i][j];
            B[j][i] = tmp;
        }
    }    
}

/*
 * registerFunctions - This function registers your transpose
 *     functions with the driver.  At runtime, the driver will
 *     evaluate each of the registered functions and summarize their
 *     performance. This is a handy way to experiment with different
 *     transpose strategies.
 */
void registerFunctions()
{
    /* Register your solution function */
    registerTransFunction(transpose_submit, transpose_submit_desc); 

    /* Register any additional transpose functions */
    registerTransFunction(trans, trans_desc); 

}

/* 
 * is_transpose - This helper function checks if B is the transpose of
 *     A. You can check the correctness of your transpose by calling
 *     it before returning from the transpose function.
 */
int is_transpose(int M, int N, int A[N][M], int B[M][N])
{
    int i, j;

    for (i = 0; i < N; i++) {
        for (j = 0; j < M; ++j) {
            if (A[i][j] != B[j][i]) {
                return 0;
            }
        }
    }
    return 1;
}

CISC 与 RISC 指令集

CISC：复杂指令计算机 (如x86-64) RISC：精简指令计算机 (如RISC-V)

RISC 相较于CISC通常指令数量更少，编码更规整，寻址模式更简单，对机器级程序实现细节可见...... RISC指令集设计简约，便于流水线优化；CISC指令集表达能力强，常能用更少指令完成同样任务，两者各有优势 比较新的CISC处理器也采用了流水线和微操作等结构，外部以CISC作为接口，内部实现会把复杂指令拆成更简单的操作；RISC在嵌入式领域也有广泛应用

Y86-64

本章使用了一种简化的$x86-64$指令集，同时结合了部分$RISC$的特点，称为$Y86-64$指令集

程序可见状态

程序可见状态对使用汇编语言的程序员和产生机器级代码的编译器都可见 $Y86-64$中，程序可见状态包括15个寄存器，条件码，PC，虚拟内存，以及状态码

可用指令

$Y86-64$只包含8字节整数操作，指令格式与$x86-64$ AT&T格式类似 mov 指令需要两个前缀，为以下之一：i立即数，r寄存器，m内存 这两个前缀分别为源和目的 操作指令addq subq andq xorq只能对寄存器进行操作，无法操作内存 跳转指令和条件传送指令与$x86-64$保持一致 call ret pushq popq与$x86-64$保持一致 halt指令停止处理器的运行，并将状态码设置为HLT

指令的编码

我们以指令 rmmov %rsp,0x123456789abcd(%rdx)为例，rmmov的指令编码为40，%rsp %rdx的编码为42，最后的偏移量字节序列为$000123456789abcd$，注意是小端法，按照字节间反序得到偏移量编码为$cdab896745230100$,进而得到整条指令编码为$4042cdab896745230100$

Y86-64指令异常

Y86-64程序

伪指令：以.开头的指令为汇编器伪指令，使得汇编器调整地址，将汇编代码或者数据存放在指定的地址

实例：

补充：在x86-64和Y86-64语义下，pushq %rsp压入的是执行压栈前的栈指针旧值；popq %rsp会把旧栈顶处弹出的值写入%rsp

硬件控制语言HCL

HCL只表达硬件设计的控制部分，不关心硬件的具体实现而是考虑怎样将处理器中的各个部分联系起来，是HDL的一个真子集 HDL 和 HCL 的对比可以参考本节，以下部分会很快带过

逻辑门

逻辑门是活动的，输入变化后输出几乎是立即变化

组合电路

组合电路需要满足以下条件

1. 逻辑门的输入必须连接到主输入，存储器单元输入，另一个逻辑门的输出三者之一
2. 两个或多个逻辑门输出不能连接在一起
3. 构成的网无环 组合电路的输出值会随着输入值变化，而C中的只有在遇到赋值的时候才会变化 MUX函数

字级的组合电路

由多个位级的组合门得到字级的抽象 多路MUX的HCL语法

注意：不要求$select_i$之间互斥，即返回的结果是第一个满足$select_i$后面的值

ALU

集合关系

时序逻辑

组合逻辑不存储任何信息，只是对输入信号输出其对应的函数值

而时序电路受到时钟控制，通常在时钟上升沿更新存储器的值 存储器都采用时序逻辑，更具体来说，分为以下两种存储器

1. 随机访问存储器：虚拟内存系统和一组寄存器，存储多个字，采用地址或寄存器标识符进行访问
2. 时钟寄存器：程序计数器，条件码寄存器，状态寄存器，存储单个位或字

存储器的读写

可以通过修改$srcA$或$srcB$为需要读取的寄存器编号，寄存器文件会组合逻辑地从$valA$,$valB$输出相应寄存器的值；写入则在时钟上升沿根据$dest$完成

内存的读写也类似：读操作根据地址产生输出值，写操作则在受时钟控制的写入时刻把输入数据写入相应地址

指令集的顺序实现

以下以$Y86-64$作为一个简化的模型进行讨论，不考虑流水线化等优化

处理指令的各个阶段

1. 取指：根据指令的确定指令的操作与功能，并得到操作需要用到的寄存器以及常数(如果该指令需要用到这些)，同时计算没有跳转的情况下下一条指令$PC$应该指向的地址$valP$(此时的PC加上当前指令的字节长度) 2.译码：通过访问寄存器得到相应的值(如果该指令需要用) 3.执行：对于计算操作，ALU计算相应的值，并且设置条件码；对于传送指令，计算传送的地址；对于跳转操作，检查条件码是否成立，得到布尔值$Cnd$ 4.访存：从内存中读出数据或者向内存写入数据 5.写回：向寄存器写入数据 6.更新PC：若$Cnd$成立，则将PC设置为跳转的地址，否则设置为$valP$

Y86-64指令执行的阶段

SEQ 顺序处理器

引入了一种叫做$SEQ$的顺序执行的处理器，每条指令在一个时钟周期内完成

SEQ的硬件结构

注意：处理器遵循“用不回读”原则，在同一个时钟周期内即不会修改一个存储器后再读取这个存储器的值

SEQ的HCL实现

以下是控制逻辑中必须显示使用的常量在HCL中的定义

取指阶段

通过指令第一个字节中包含的指令功能，判断得到是否需要读入寄存器和常数($Need_regids$和$Need_valC$) 当该指令不合法时(当前指令地址不合法或不存在功能码对应的指令)，会将当前指令设置为$nop$所对应的代码 然后根据$Need_regids$，若该值为真，将$rA$,$rB$设置为第二个字节的两个四位二进制数，否则设置为$0xF$(空寄存器) 若$Need_valC$为真，当$Need_redigs$为真的时候在第3到10个字节取得常数，为假的时候在第2到9个字节取得常数 最后，将$valP$(下一个指令起始地址)设置为$PC+1+Need_regids+8*Need_valC$

例：

访问寄存器

译码，写回两个阶段本质都是对寄存器的访问 通过$srcA$,$srcB$访问相应的寄存器，结果从$valA$,$valB$读出 通过$dstE$,$dstM$进行写入同理 当某个地址访问端口上的值为$0xF$时，则表示不需要读取/写入

例：

执行阶段

ALU接收三个参数$aluB$,$aluA$,$alufun$，得到结果$valE$并设置条件码 注意当运算为减法时不符合交换律，需要保证得到的结果为$aluB-aluA$，故需要将$aluB$放在前面

例：

条件码会和指令的功能一同传入黑箱$cond$中，黑箱传出信号决定$Cnd$用于条件跳转和条件传送

访问内存

通过$Mem.read$和$Mem.write$控制是写还是读，$Mem.addr$控制读写的地址，$Mem.data$控制写入值，$valM$得到读取值

例：

更新PC状态

PC可能的新值为顺序下一条指令的地址，使用函数或结束函数跳转到的地址，条件跳转的地址 从这几个地址中选择即可

无反馈的流水线系统

在SEQ中，我们必须等待上一条指令按照阶段顺序依次完成，一个时钟周期结束后才能开始处理下一条指令，每个单元只在时钟周期的某一段时间内被使用。 通过流水线化，系统的整体延迟虽然增加，但是吞吐量增大。

流水线基本原理

注：$1ps=10^{-12}s$

延迟：一条指令从头到尾运行完毕需要的时间，这个例子中为$20ps+300ps=320ps$ 吞吐量：单位时间内能完成的指令数，即 $\frac{\text{完成指令数}}{\text{执行时间}}$，这个例子中为 $\frac{1}{320ps}=3.12GIPS$（GIPS: 每秒十亿条指令）

流水化后：

将组合逻辑拆解为几个子阶段，并引入寄存器保存每个子阶段的结果 为了保证电位上升时，所有子阶段的结果都已经计算完毕，能够写入寄存器中，时钟周期需要取子阶段耗时的最大值 每过一个时钟周期，相关数据从寄存器中读取并进入到下一个子阶段，同时在第一阶段加入新的指令，在最后一阶段结束流水线中最早的一条指令 流水化后，因为引入了寄存器，增大了时钟周期，使得执行一条指令的延迟增加了；但是由于能够同时执行多条指令，吞吐量增加了 以该图为例子，时钟周期变为$\max{100+20,100+20,100+20}=120ps$，延迟为$120ps\times3=360ps$，吞吐量为$\frac{1}{\text{时钟周期}}=\frac{1}{120ps}=8.33GIPS$

流水线加速的限制因素

1. 子阶段划分不一致：时钟周期由最慢的子阶段延迟决定，而部分硬件单元，如$ALU$和内存无法划分成更小的部分
2. 流水线过深：流水线子阶段划分过多，此时寄存器开销是决定性因素，吞吐量提升很小，总延迟反而增加比较多，同时也增大了预测错误，数据冒险的惩罚

五级流水线的实现

以下简称流水线的五个阶段分别为F(Fetch)，D(Decode)，E(Execute)，M(Memory)，W(Write)

PC计算阶段提前进行

PC计算阶段并入取指阶段中，影响PC更新的寄存器来自前一个周期产生的控制信号，使得能够立即得到下一条指令的地址，以便其加入流水线

插入流水线寄存器

通过插入流水线寄存器保存流水线各阶段之间的信息，使得其得以自底向上流动

PC的预测

当目前取指的指令为条件跳转或ret时，必须在访存\执行阶段才能得到跳转指令的地址，处理器通过预测下一个PC值保证流水线尽量被填满 对于条件跳转操作，处理器使用分支预测，例如按照总是选择或从不选择来填充流水线，一种简单而比较有效的预测逻辑是“反向选择，正向不选择”，即向更低地址的跳转预测为真，向更高的预测为假，因为循环的汇编表示都是条件成立时向更小的地址跳转，而循环一般会执行多次，预测只有最后一次才会出错 对于ret操作，简化的Y86-64流水线通常需要暂停取指，直到返回地址从栈中读出；真实处理器常用返回地址栈预测ret目标，预测通常相当准确，除非返回地址栈失配或溢出

带反馈的流水线系统

流水线冒险

数据冒险：此后的指令会用到当前指令相关的数据，而这个数据还未写入内存/寄存器中导致后续使用了错误的数据 控制冒险：执行跳转，引用，返回等指令时，PC预测可能出现错误

避免数据冒险

暂停

当下一步继续进行会产生数据冒险时，处理器会动态加入气泡(作用类似nop指令)，来将后续受影响的指令停止在取指阶段，直到最深的一条指令通过写回阶段再继续进行

转发

在基本的硬件结构中增加一些额外的数据连接和控制逻辑，使得更深的指令得以在数据已经计算完毕但还未来得及写入的情况下，直接将该数据写入受影响的指令的流水线寄存器中，避免了指令的停止

转发与暂停的结合

当更深指令尚未得到与后面受影响的指令相关的数据时(如读取内存的值写入寄存器，直到M阶段才能得到该数据)，处理器会动态产生气泡，直到得到该数据，能够进行转发

避免控制冒险

当跳转指令已经执行完F和D阶段，在E阶段发现预测出错，此时后面两条指令分别在D和F阶段，未对任何程序员可见状态进行修改，只需要在下一个时钟周期时向D和E阶段插入气泡，同时取出正确跳转地址的指令，就能从流水线中排除这两条错误指令

异常处理

可能存在以下三种内部异常情况：halt指令，指令异常，地址异常。在产生异常时，最流水线深的一条指令(对应源汇编代码中靠前的指令)的异常会被报告到状态码中，在异常状态下，寄存器和内存被禁止更新，导致异常的指令继续沿着流水线传播，直到写回阶段，流水线控制逻辑发现异常并停止执行

流水线的HCL实现

咕咕咕

流水线的性能分析

我们用$CPI$即执行每条指令所需时钟周期衡量流水线的性能 当执行的指令足够多时，我们可以忽略启动指令经过流水线的周期，此时执行的指令数$C_i$与气泡数$C_b$之和近似等于消耗的时钟周期 所以有$CPI=\frac{C_i+C_b}{C_i}=1.0+\frac{C_b}{C_i}$，其中$\frac{C_b}{C_i}$是平均每条指令插入的气泡数，受到加载处罚，预测错误分支处罚，返回处罚影响，其中预测错误分支处罚为主要因素 比较新的处理器支持超标量操作和乱序执行技术，可以使得$CPI$小于1.0

编译过程

以GCC编译C语言为例 linux> gcc -Og -o hello hello.c (-Og 优化等级低，避免机器代码严重变形，便于进行调试)

1. 预处理：将预处理指令进行替换 (头文件包含，宏展开，条件编译#if #ifdef #endif...)，删除注释，得到处理后的.iC代码
2. 编译：将.i文件进行编译得到.s汇编语言文件
3. 汇编：将.s翻译成机器指令，得到二进制文件 (windows下.obj linux下.o)
4. 链接：将.o文件和所需要的库文件组合在一起(头文件的函数在预处理中只声明，链接定位函数的具体实现)，生成可执行文件

linux> gcc -Og -S hello.c 产生一个汇编文件 hello.s linux> gcc -Og -c hello.c 产生二进制文件hello.o linux> objdump -d hello.o 实现反汇编

机器级代码概述

指令集架构(ISA Instruction Set Architecture) 定义机器级代码的格式和行为，虽然指令在ISA层面被描述为顺序执行，但现代处理器采用流水线、乱序执行等技术实现并发执行，最终结果与顺序执行一致 x86系列：8086(16位架构) $\rightarrow$ IA-32 (32位架构) $\rightarrow$ x86-64(64位架构) 机器级程序看到的是字节级虚拟地址空间，操作系统和硬件负责将虚拟地址翻译成对应的物理地址 一条机器代码一般只执行非常基本的操作，如寄存器中两个数相加，存储器与寄存器之间传送数据，条件分支转移到新的指令地址等

汇编代码格式：AT&T与Intel

1. Intel 代码省略了指示大小的后缀:movq $\rightarrow$ mov
2. Intel 代码省略寄存器前面的"%":%rax $\rightarrow$ rax
3. Intel 代码描述内存的方式不同:(%rax) $\rightarrow$ QWORD PTR [rax]
4. Intel 与 AT&T列出操作数的顺序相反: movq %rax, %rbx $\rightarrow$ mov rbx, rax

本文采用x86-64 AT&T格式

机器代码的优势：性能优化，访问硬件特性(PC,寄存器)，更难逆向分析

数据的传输

数据格式

最初的架构为16位，所以Intel用 字(word) 表示16位，32位为双字(double words/long word)，64位为四字(quad words)

GCC生成的部分汇编代码指令都带有一个字符后缀表示操作的大小，如movl表示传送双字

信息访问

x86-64 CPU 中含有16个通用寄存器

8086中含有%ax到%sp8个通用寄存器 IA32将这8个寄存器扩展为32位 (%eax中的"e":extended) x86-64将寄存器扩展到64位(%rax中的"r":register整个寄存器)，并采用新的命名方式增加8个寄存器(%r8～%r15，%r8d中的"d":double words，%r8w中的"w":word) 指令通过不同的后缀大小(b,w,l,q)，得以访问寄存器的不同最低字节(1,2,4,8) 小于8字节的数据传送到寄存器中时，若传送字节为1或2，则更高的字节不变；若传送字节为4，则更高的4个字节全置为0(IA32到x86-64扩展导致的)

操作数指示符

将寄存器看做数组$R[]$，内存看做数组$M[]$

1. 立即数(immediate):$后面接常数 eg. $114514
2. 寄存器(register):以指定寄存器的低位1,2,4,8字节为操作数，返回寄存器中的值即$R[r_a]$ eg. %eax返回第一个寄存器的低32位
3. 内存引用：将内存看做很大的字节数组，根据计算的有效地址访问内存位置

内存引用的寻址模式：$Imm(r_b,r_i,s)$，其中$Imm$为立即数偏移，$r_b$和$r_i$为64位寄存器，$s$取1,2,4,8(默认为1) 有效地址被计算为$addr=Imm+R[r_b]+R[r_i]*s$，返回$M[addr]$

数据传送指令

将数据从一个位置传送到另一个位置的指令

MOV

MOV S, D指将数据从$S$复制到$D$，其中$S$称为源操作数，$D$称为目的操作数

其中源操作数可以取立即数，寄存器，内存；目的操作数可以取寄存器和内存 注意：x86架构中大部分操作(包括MOV)源操作数和目的操作数不能同时为内存，必须通过寄存器进行中转 $movabsq$作用：处理立即数时，$movq$只能传送32位立即数然后在符号扩展到64位，而$movabsq$能将64位立即数直接传送到寄存器，但只能移动立即数

MOVZ与MOVS

两者都是将较小源值复制到较大的目的值，后缀都有两个大小指示符，分别是源的大小和目的的大小 MOVZ 采用零扩展进行复制，无符号数扩展

注：没有movzlq的原因是使用movl传送4个字节会把前面更高的4个字节全赋为0，两者等价

MOVS采用符号扩展进行复制，有符号数扩展

压入和弹出栈数据

x86-64架构中，程序栈放在内存中某个区域，寄存器%rsp保存栈顶的地址 不同于C语言中用数组模拟实现栈时栈顶指针指向地址最高，%rsp指向的栈顶地址是栈中最小的

pushq %rbp等价于subq $8,%rsp movq %rbp,(%rsp)，即将栈顶指针向前移动8个字节，再将元素入栈 pushq的优势：编码为1个字节，而等价代码编码为8个字节；同时现代x86-64处理器上pushq被高度优化，效率更高 栈内数据在内存中，同样可以用内存寻址法访问

算术和逻辑操作

四类操作：加载有效地址，一元操作，二元操作，移位 这里主要讨论leaq的64位形式；其他算术逻辑指令通常能用不同后缀(b,w,l,q)指示操作大小

加载有效地址

lea:load effective address leaq Imm(r_b,r_i,s), r_d 表示采用内存计算的方法算出地址之后，将该有效地址作为数字直接存储到$r_d$中 eg. 设%rbx的值为$x$，则 leaq 6(%rbx,%rbx,4), %rax 表示计算$5 \times x + 6$并存放在%rax中 作用：简洁地表示普通的算术操作

一元操作和二元操作

一元操作中的操作数既是源操作数又是目的操作数；二元操作中前者为源操作数，后者为目的操作数 eg. subq %rbx,%rax表示将$R[rax]$减去$R[rbx]$ 同样，二元操作也不能源和目的都为内存，需要进行寄存器的中转

移位操作

SAR表示算术右移(Shift Arithmetic Right)，SHR表示逻辑右移 为了对称，同时有SAL和SHL，但是两者作用完全等价，SHL更为常用 移位操作有两个操作数，前者为移位数(立即数或者%cl中的数 不能是其他寄存器或内存中的数)，后者为移位的对象(内存或寄存器) 注：移位操作实际使用的移位位数为指令大小后缀对应的低位，如$sarl$实际移位数位给定数对32取模 eg. shlq $65, %rax 即为将%rax中的数左移1位

特殊算术操作

两个64位整数相乘时需要得到128位整数再进行截断，其中16字节的数称为八字(oct words)

imulq 的第一种形式：imulq S, D 将 D 乘以 S，结果存储在 D 中 imulq的第二种形式：IMUL S，另一个参数在%rax中，乘积得到的128位结果高64位放在%rdx中，低64位放在%rax中($__int128$)

idivq(有符号除法):将%rdx看做高64位，%rax看做低64位得到128位被除数，除数作为指令操作数给出，商存放在%rax中，余数存放在%rdx中 当被除数为64位时，cqto指令通过符号扩展将被除数扩展到128位

divq(无符号除法)：事先将%rdx设置为0，可以使用xorq %rdx, %rdx

控制

使得指令按一定的顺序执行(顺序结构，选择结构，循环结构)

条件码

部分指令(如计算，比较和测试，移位等)会设置条件码 注：leaq计算地址，不会设置条件码

CMP，TEST进行类似于SUB和AND的计算，不同之处在于不会将结果写入目的位置，而只会设置条件码

通过CMP a, b可以得到$b-a$对应的条件码，从而判断$a$和$b$的相对大小；通过TEST a, a可以将$a$的零值和符号等特征反映到条件码中

访问条件码

SET通过条件码的组合，将是否满足后缀条件(0/1布尔值)传送到一个低位字节中

如假设$a$存储在%rsi中，$b$存储在%rdi中，执行cmpq %rdi, %rsi后 setl %al表示将%rax的最低字节设置为$(bool) (a < b)$，结果字节为0或1

跳转指令

将指令执行的顺序改变，跳转到一个指定的位置

格式类似C中的goto-label：

jmp被称为无条件跳转，其余被称为条件跳转 只有无条件跳转能执行间接跳转，如jmp *%rax跳转到%rax的值对应地址的指令，jmp *(%rax)跳转到%rax指向内存的值对应地址的指令

跳转指令的编码

将汇编代码编码后，跳转目标通常会被编码为1、2或4字节的位移量，其值等于目标地址减去当前跳转指令的下一条指令地址(PC相对寻址，使得代码与位置无关，便于加载共享库)

如图所示，编码后文件每一行冒号前的数字表示该指令编码得到的第一个字节的地址 第二行中通过$0x05 + 0x03 = 0x08$得到这条指令会跳转到地址$08$即第四行执行 第五行中通过$0x0d + 0xf8 = 0x05$(注意是有符号运算)得到这条指令会跳转到地址$05$即第三行执行

条件传送与条件控制

汇编使用$JMP$实现$if-else$和$goto-lable$进行跳转被称为条件控制

在一些特殊情况下，使用CMOV(conditional move) 的条件传送更为高效

CMOV需要加上条件后缀，操作数大小通常可由寄存器名或汇编器推断；它只支持字、双字和四字形式，不支持单字节条件传送 当条件码满足的时候，CMOV a, b 会将$a$的值写入$b$ 使用条件传送实现$if-else$：

if (condition){
	a = if_expr;
}
else {
	a = else_expr;
}

使用条件传送实现等价的代码为

int x = if_expr;
int y = else_expr;
a = condition? x:y; 

注意，以下代码不能使用条件传送

原因：不论是否为空指针，都会提前计算$0$和$*xp$，在指针为空的情况下会导致$UB$

相较于条件控制，条件传送在一些情况下更为高效 原因：现代处理器使用流水线来得到高性能，即通过预先确定要执行的指令序列来使得流水线尽量充满。在遇见指令的跳转时，处理器通过分支预测逻辑猜测是否会进行跳转，并按猜测的结果为后续指令预处理。当猜测出错时，处理器只能丢掉已经做过的处理，重新填充流水线导致效率大大降低。在是否跳转极其难以预测的情况下(如if (x & 1))，性能会受到严重影响。而条件传送没有改变程序计数器(PC)，下一条指令的地址确定，保证了流水线尽量填满。

编译器会在两个分支计算简单且计算代价差异小，分支难以预测，无副作用，优化程度高(-O2 -O3)的情况下优先选择条件传送

switch 语句

在开关大跨度稀疏时，switch会被编译为条件控制 在开关小跨度密集时，switch会被编译为跳转表

eg. 左侧为C源代码，右侧为与跳转表类似的C实现 (&&表示指向代码位置的指针)

编译得到跳转表。表中每一项保存一个目标代码地址或相对位移，相邻表项通常按指针大小排列，并不是相邻的label只相差1个字节

汇编代码

循环

将条件测试和跳转组合起来即可得到循环

do-while

while有两种形式

1. jump to middle(先进入循环，在循环中途再检查条件)

2.guarded-do(先检查条件，再进入循环)

for

注意：当在$body-statement$中存在$continue$语句时，$continue$应当跳转到$update-expr$部分，否则可能导致死循环等问题 现代编译器会根据循环特征自动选择最优的实现方式，并进行循环展开等优化

过程

一种封装代码的方式，隐藏具体的实现，同时提供清晰的接口(类比C中的函数) 过程包含的机制(假设从过程$P$进入过程$Q$)：

1. 传递控制：将PC设为$Q$过程起始指令的地址，执行完$Q$过程后再将$PC$设置为$P$中调用$Q$下一条指令的地址
2. 传递数据：$P$将特定的参数传递到过程$Q$中,同时$Q$向$P$传递返回值
3. 内存的分配与释放：为局部变量分配空间，并在过程结束时将这些空间释放

运行时栈

在过程$Q$被执行时，其调用链上的所有信息的挂起在栈上，栈中存放着传递控制，传递数据，内存分配释放的信息 栈帧：过程在寄存器中存放不下，存放在栈中的空间 局部变量都可以存储在寄存器中并且为叶子过程(未调用其他过程的过程)，则不需要栈帧 注:%rsp为栈指针，％rip为PC

传递控制

从过程$P$到过程$Q$ call Q将PC跳转到$Q$起始指令的地址，并将call指令的下一条地址(返回地址)压入栈中 ret从栈中弹出返回地址，并将PC设置为返回地址

传递数据

$x86-64$架构中最多可以用6个寄存器来传送参数

当传递的参数大于6时，需要通过栈来进行传送(参数构造区)

eg.

注：通过栈传送数据时，第7个及以后的参数按从右到左的顺序压入栈中，第7个参数在栈顶（低地址），后续参数依次向高地址排列

内存的分配与释放

当寄存器不足以存放局部数据，或者局部数据被取地址(&)需要被分配地址时，会在栈上为这个数据分配空间，形成局部变量

eg.

其中：

1. x1 x2 x3被取地址，作为局部变量在栈上分配空间，同时也属于前6个参数，传入寄存器
2. &x1 &x2 &x3属于前6个参数，传入寄存器，又未在该过程后续被直接使用，不是局部变量
3. x4被取地址，作为局部变量在栈上分配空间，同时也在栈上再次分配一个不同的空间，传送这个参数
4. &x4通过在栈上分配空间作为参数传送，但不是局部变量

在执行call proc时，会在栈中压入长8个字节的返回地址，使得$x4$和$&x4$相对栈的地址偏移量变为8和16个字节，proc过程得以正确执行 注意： 栈帧内存的释放只是改变了栈指针，没有改变曾经的参数和局部变量的值，意外访问这些位置可能读到旧数据

寄存器中的局部存储空间

被调用者保存寄存器：%rbx, %rbp, %r12-%r15（调用前后值不变） 过程$P$调用过程$Q$，当过程$Q$回到过程$P$时，必须保证以上寄存器的值与其调用$Q$前的值相等 这些寄存器可以作为临时变量，保存$P$中的某些信息，防止在$Q$中这些信息被改变(如参数，$P$和$Q$参数可能不同) 实现：将过程中要使用的作为临时变量的寄存器，在过程开始时压入栈中，中间任意变换，结束过程时再从栈中弹出覆盖这些寄存器的值即可

调用者保存寄存器：%rax, %rcx, %rdx, %rsi, %rdi, %r8-%r11（调用后可能被修改）

eg.

递归过程

每个过程相关信息在栈上都有私有空间，互不干扰，使得递归能够高效而正确地实现

eg.

当递归调用是函数体中最后执行的操作时，编译器可能进行尾递归优化，将其转换为循环

数组的分配与访问

通过对数组首地址进行运算，得到需要访问的元素的地址 eg. T A[N]会在内存中以$x_A$开始，连续分配$L\times N$大小的空间，其中$L$为单个$T$的大小 A[i]的地址 $&A[i] = x_A + i \times L$ 例如，假设$i$的值存放在%rcx中，int数组首地址$x_A$在%rdx中，通过movl (%rdx, %rcx, 4), %rax即可将$A[i]$的值存放在%rax中

对于二维数组T A[N][M]来说，有 $&A[i][j] = x_A + L \times i \times M + L \times j = x_A + L \times (i \times M + j)$

以此类推，对于$k$维数组T A[N][][]....来说，其$&A[i][][]...$等于 $x_A$ + $i \times L(A[][]...)$ + $k-1$维中访问$A[][]...$的地址偏移量

定长数组与变长数组

编译器对定长数组(数组大小为常量)的优化： 通过指针加减移动进行寻址，而非用乘法进行寻址，提高寻址的效率

对于变长数组(数组大小为表达式)：

由于数组的大小不确定，无法使用leaq，需要使用imul，时间开销更大，但编译器仍然尽量使用指针提高效率

异质的数据结构

struct 结构

同一结构内的变量都分配在连续的内存中 eg.

struct str{
	int l, r;
	long long val;
}s;

其中s是一个结构体对象；若%rdx中存放的是指向s的指针，则通过8(%rdx)即可以访问s.val

联合 union

eg.

struct node_t { 
	nodetype_t type; 
	union { 
		struct { 
			node_t *left; 
			node_t *right; 
		} internal; 
		double data[2]; 
	} info; 
}; 

其中，internal与data[2]互斥 (若为叶子节点则只有两个值，没有儿子指针；若不是叶子节点，则有两个儿子指针，无权值) union的大小为其中最大变量的大小，如以上的union中所占大小为16，通过union节省了空间

同时，union也可以实现保持位模式相同的类型转换

double x = 114514.1919810;
unsigned val = (unsigned)x;

这是普通数值转换：浮点数会向零舍入；如果超出unsigned可表示范围，行为不由C标准保证

union{
	double x;
	uint64_t val;
}u;
u.x = 114514.1919810;
uint64_t val = u.val;

通过union，可以观察同一段存储的位模式；这里用64位整数保存double的完整二进制串，数值含义会发生改变

数据对齐

对于结构体中的变量，编译器通过数据对齐保证其地址为$K$的倍数($K=1,2,4,8$)，进而提高访问的效率 例如假设处理器每次操作从内存中取8个字节，对$double$进行字节对齐，使其不会落在两个不同的内存块中，保证了读写时处理器只会访问一个内存块，进而保证了操作的高效

字节对齐按以下步骤进行：

1. 对于结构内的某个变量，在其后面的地址连续填充空隙，直到下一个地址满足下一个变量所需的对齐约束，再将下一个变量放入这个地址中
2. 设$M$为结构内所有变量的最大对齐要求，在最后一个变量之后连续填充空隙，直到结构体总大小为$M$的倍数

eg.

struct str{
	int a;
	char b;
	int c;
	char d;
};

其对齐后的结果为： a: 0～3 b:4～4 空隙:5～7 c:8～11 d:12～12 空隙:13～15

杂项

指针

指针本质是一个二进制串表示的地址，其类型决定了每次对指针运算时的大小偏移量 对于指针类型强制转换，只会改变其每次的偏移量，而不改变指向的地址 eg. int *p; p++;会让p指向的地址向后移动四个字节 指针同样能够指向函数，即指向函数首指令的地址

缓冲区溢出

以C中的$gets$为例(不给定目标缓冲区的大小)，当读入的字符大于定义的字符数组长度时，就可能越界访问当前函数的返回地址和栈中保存的其他函数状态

缓冲区溢出攻击

通过在输入的字符串中加入可执行代码(攻击代码)，同时又用指向攻击代码的指针覆盖返回地址，导致系统被攻击 对抗溢出攻击

1. 栈随机化：通过执行代码前分配一段长度为$0 \sim n$个随机字节且不使用的空间，使得每次运行时的栈地址不固定，攻击时不一定能跳转到攻击代码 局限：nop sled 通过在攻击代码写入大量的nop,只要能跳转到其中任意一个nop就能执行攻击代码 eg. 32位系统随机地址范围大小大约为$2^{23}$字节，在攻击代码前写入$m$字节大小的nop，执行$\frac{2^{23}}{m}$ 次则一定会跳转到攻击代码 如取$m=256$，则大约需要三万次左右次枚举起始地址，攻击就能成功
2. 栈破坏检测:通过在栈中插入一个运行时随机生成的金丝雀值(canary)，恢复栈的状态时，若该值被改变，则发生了溢出攻击，程序跳转到错误处理例程 其中canary会和保存在安全位置的原始值比较，攻击者通常难以预测并正确伪造它 注意：现代编译器默认采用栈破坏检测，gcc中可采用-fno-stack-protector将其关闭 3.限制可执行代码区域：将栈上的某些部分设置为可读可写但不能执行($NX$)

浮点代码 (AVX2)

"我们不太清楚GCC为什么会生成这样的代码，这样做既没有好处，也没有必要在XMM寄存器中把这个值复制一遍" 看破防了，感觉CSAPP也是讲得稀里糊涂的，以后再补

数字的存储

内存被划分为不同大小的字块，32位CPU->4字节，64位CPU->8字节 对字长$w$的机器而言，虚拟地址范围为$0～2^w-1$，即有$2^w$个字节 64位架构地址空间限制为48位虚拟地址，约为$256TB$($2^{48}Bytes$)，但是仍然在64位逻辑上处理算术运算 编译器通过保持字节对齐，提高硬件效率 无论32位机器还是64位机器，int32_t和int64_t都分别占4个和8个字节；int和long等C类型的大小取决于具体ABI。32位机器也可以支持64位整数运算，只是通常需要用多条32位指令协同完成 而浮点寄存器有自己的宽度标准，与通用寄存器宽度无关，如$double$始终占8个字节

小端法：最低有效位所在字节存储地址在最前面，类型转换灵活，符合数学思维 大端法：最高有效位所在字节存储地址在最前面，方便阅读识别，便于判断正负 大小端法通常由ISA/系统ABI共同约定，有些架构还支持在不同模式下选择字节序 x86/x86-64使用小端法 PowerPC，网络协议(TCP/IP)使用大端法 ARM, RISC-V, MIPS等同时支持两种字节序

二进制下的整数

1. 补码

对于 $w$ 位的无符号整数$x$：$x = \sum\limits_{i=0}^{w-1}a_i \times2^i$ 对于$w$位的有符号整数$x$ : $x = -2^{w-1} \times a_{w - 1}+\sum\limits_{i=0}^{w-2}a_i \times2^i$(补码表示) 在此种表示方式下，$-x$的补码编码与无符号整数$2^w-x$的编码相同 原理：在$mod$ $2^w$ 意义下 $-x$ 与 $2^w - x$等价，无符号运算在溢出的情况下仍满足加法与乘法结合律，交换律等定律 无符号整数与有符号整数的比较：有符号整数类型转换为无符号整数再进行比较 $eg$: $-1$ $>$ $0U$ 有符号整数与无符号整数的转换： 若有符号数$t < 0$，则其无符号解释为$t + 2^w$；若$t \geq 0$，则无符号解释仍为$t$ 若无符号数$u > 2^{w-1}-1$，则其有符号解释为$u - 2^w$；否则仍为$u$

2.符号扩展与数字截断

符号扩展：在不改变值的情况下提升一个$w$位有符号整数的位数

case1:若符号位$a_{w-1} = 0$

直接将$a_w$设为$0$，扩展到了$w+1$位

case2:若符号位$a_{w-1}=1$

将第$a_w$设为$1$，第$a_w$和$a_{w-1}$的贡献从$-2^{w-1}$到$-2^{w}+2^{w-1}$不变，扩展到了$w+1$位 即扩展到第$w+1$位时有$a_w=a_{w-1}$

数字截断到$k$位：保留最低$k$位，舍弃第$k$位及更高位 无符号数数字截断等价于对$2^k$取模

从较小整数类型转换到较大整数类型时，C会先进行整数提升：有符号源通常符号扩展，无符号源通常零扩展，然后再按目标类型解释位模式 eg. 对于short x; (unsigned)x等价于(unsigned)(int)x

3.运算

对于两个$w$位整数的运算，加法得到的结果最多为$w+1$位，截断第$w+1$位得到$w$位整数，对无符号整数来说等价于对结果$mod$ $2^w$ 乘法得到的结果最多为$2w$位，保留低$w$位并舍弃高位得到$w$位整数 $w$位整数与常数相乘的时候，编译器会根据上下文进行优化，优化方式取决于架构的指令集 eg. x*14=(x<<3)+(x<<2)+(x<<1)或((x<<3)-x)<<2（乘法分解为位移和加减法） 或imul eax, edi, 14（编译器认为imul更快，直接使用乘法指令）

逻辑右移：右移一位后在最高位补0 算术右移：右移一位后，若符号位原本为1，则在最高位补1，否则补0 除以2的幂时： 无符号数采用逻辑右移，等价于向下取整 有符号数需要特殊处理：编译器会生成先加偏置再算术右移的代码，以保证向零取整的结果与C语言标准一致

二进制下的浮点数

1.浮点数的表示

标准化之前

对浮点数$x$有：$x=\sum \limits_{i=-j}^{k}a_i \times2^i$ 左移，右移在算术上仍然等价于$\times2$ 和 $\div 2$，但是误差大，受位数有限制约 标准浮点数表示法：IEEE浮点数

IEEE浮点数

符号位(s) + 阶码位(exp) + 尾数位(frac) 单精度32位 双精度64位 (和英特尔扩展精度80位) 32 = 1 + 8 + 23 64 = 1 + 11 + 52

IEEE浮点标准用$V=(-1)^s \times 2^E * M$表示浮点数

设$exp=\sum\limits_{i=0}^{k-1}2^ie_i$,$bias=2^{k-1}-1$(无符号整数) $frac = \sum\limits_{i=0}^{n-1}f_i\times2^{i-n}$(分数)

1.规格化的情况($1 \leq exp \leq 2^k-2$) $E=exp-bias$，$M=1.0 + frac$，那么有$-2^{k-1} + 2 \leq E \leq 2^{k-1} -1$

2.非规格化的情况($exp = 0$) $E=1-bias$，$M=frac$ 用来表示$0$和极其接近$0$的值 注：$+0.0$和$-0.0$有不同的位表示，但在普通数值比较中相等

3.特殊值($exp = 2^k-1$) $frac = 0$:$V=INF$ $frac \neq 0$:$V=NaN$

注： 1.引入$bias$的意义：阶码无需引入符号位；对同号规格化浮点数，阶码和尾数的位模式顺序更接近数值大小顺序 2.非规格化情况下$E$取$1-bias$，使得非规格化最大值为$2^{2-{2^{k-1}}} \times (1-{2^{-n}})$，而规格化最小值为$2^{2-{2^{k-1}}}$，二者十分接近

2.整数转浮点数

以将(int)114转换为float为例

1.转为二进制下科学计数法 $114 = (1110010)_2 = (1.110010)_2 \times 2 ^ 6$ 2.去掉小数点前的1并在末尾添加0直到$n$(23)位，得到尾数部分 $1.110010 -> 11001000000000000000000$ 3.将阶数加上偏移值$2^{k-1}-1$(127)，转为二进制得到阶码部分 $6 + 127 = 133 ＝ (10000101)_2$ 4.加上符号位，将阶码尾数拼起来 $(01000010111001000000000000000000)_2$

由该过程可知，整数二进制编码与其浮点数表示的尾数部分除第一个1外重合

3.思考：n位位数不能精确表示的最小正整数

假设阶码足够大，有$n$位尾数的浮点数不能精确表示的最小正整数为$2^{n+1}+1$

证明：$n$位的$frac$再加上尾数隐式的$1.0$一共$n+1$位，乘$2^E$可以看做左移$E$位，在阶码可以取到无穷大的情况下，可以取遍$1 ～ 2^{n+1}-1$，同时在$frac$全为$0$的情况下，左移$n+1$位得到$2^{n+1}$，即$1～2^{n+1}$都可以表出，而$2^{n+1}+1$无法表出 推论：double能连续精确表示的最大正整数为$2^{53}=9007199254740992$，因此$2^{53}+1$不能被精确表示；但更大的2的幂或足够大的偶数仍可能精确表示 补充:$n$位尾数浮点数在$x$处的误差(可表示数的最小间隔) $ULP(x)=2^{\lfloor \log_2 \lvert x \rvert \rfloor - n}$ 警钟撅烂：double r = 1e18+5; $r$的值仍然为$10^{18}$

4.浮点数的运算

舍入：找到最接近的值$x$，使其可以按期望的浮点形式表示出来 向零舍入，向上舍入，向下舍入 向偶数舍入：优先向满足条件的最接近的数舍入，若存在两个这样的数，则向最低有效位为偶数的那个数舍入(避免了统计误差) 浮点加法，乘法运算不满足结合律，浮点乘法在加法上不存在分配律 **eg.**对于$float$有$1.14+1e18-1e18=0$（舍入导致1.14丢失），$1.14+(1e18-1e18)=1.14$ 无穷运算规则：+∞ + (+∞) = +∞，+∞ + (-∞) = NaN，+∞ × 0 = NaN NaN的传播特性：任何包含NaN的运算结果都是NaN

5.C中浮点数与有符号数的转换

$int$转$float$可能被舍入 $double$转$float$可能会溢出或者被舍入 $float,double$转整数值会向零舍入；若超出目标整数类型范围，C标准认为行为未定义。在常见x86实现中，越界或NaN转换可能产生整数不确定值$(100..00)_2$，即$-2^{w-1}$

假设处理器工作时，PC指向的指令地址构成的序列为$a_1,a_2...a_n$，序列$a$就称为处理器的控制流，由$a_i$向$a_{i+1}$的过渡称为控制转移 现代系统通过使控制流发生突变，对系统状态的变化做出反应，这些突变就称为异常控制流(Exceptional Control Flow，ECF)

异常

异常是一种响应处理器状态变化的机制，既有软件实现的部分，也有硬件实现的部分 其机制如下

假设处理器正在执行指令$I_{cur}$，此时发生一个事件(如除0，数值溢出，直接内存访问结束)，处理器会检测到该事件的发生，并通过异常表进行控制转移，跳转到相应的异常处理程序进行处理，然后返回继续执行指令或终止程序

异常的识别与调用

每一种异常都有着一个唯一的无符号数表示的异常号 在系统启动时，系统会生成一张异常表，该表的第$k$项存放了对应异常号为$k$的异常处理程序指令所在地址 而异常处理程序的调用类似于函数，但是有着一些区别：

1. 调用函数后，条件码等信息可能发生变化；调用异常处理程序时这些信息进行了压栈保存，处理结束后弹出，保证了程序的正常运行
2. 调用函数会将返回地址压入用户栈中；而调用异常处理程序会将返回地址和相关信息压入内核栈
3. 函数运行在用户模式下；而异常处理程序运行在内核模式下，有着对系统资源更完全的访问权

异常的类型

异常有以下四种类型：中断，陷阱，故障，终止 其中中断属于异步异常，而其他三种属于同步异常

中断

外部I/O设备发出信号，导致中断发生。即中断不是由内部指令造成的，所以称为异步异常 I/O设备通过向处理器芯片上的引脚发信号，并将异常号放入系统总线中进而触发中断 其流程如下：

我们以DMA直接内存访问结束为例，当磁盘访问完成时，处理器收到了对应的异常码，在调用异常处理程序后继续处理下一条指令

陷阱

陷阱是有意造成的异常，和中断相似，但区别在于是由内部指令造成的 陷阱最重要的作用是系统调用，这是用户程序和内核间的接口，通过访问内核，得以进行文件读写，创建进程等重要操作 汇编中，使用syscall进行系统调用，触发一个到异常处理程序的陷阱

故障

故障是处理器处理中出现了错误情况，它可能在被异常处理程序修正后成功重新运行(如缺页异常)，也可能无法被修复导致程序终止

注意：导致故障时当前指令尚未完成，所以如果成功修复后，需要跳转到当前指令重新执行，而非下一条指令

终止

发生了不可修复的严重错误，不返回控制，而是直接转入会结束该程序的abort例程

linux系统中的异常

我们以x86-64为例，有256个异常号，其中0～31由架构定义，对x86-64架构都一样；而32～255由操作系统定义，通常用于中断和陷阱

其中除法错误和一般保护故障(常表现为段错误)通常表示程序逻辑或权限错误，内核一般会向进程发送信号并终止它，而不是静默修复后继续运行

linux为系统调用生成了一张跳转表，每个系统调用都有一个唯一的整数号 汇编语言中，进行系统调用时，将要进行的系统调用的整数号放入%rax中，参数最多六个，依次放入%rdi、%rsi、%rdx、%r10、%r8、%r9中，然后使用指令syscall即可 进行系统调用时，%rcx和%r11会被用作临时变量，分别保存下一条指令地址和程序状态标志而被破坏掉 调用结束后的返回值会覆盖%rax，当其值为负数时，说明系统调用发生了错误

常见系统调用的跳转表如下

hello world 汇编实现

事实上，函数调用在高级语言中被高度封装成了函数(如write封装为printf)，但是我们也可以通过相关接口直接进行系统调用

进程

程序是一个静态的文件，而进程则是程序运行起来的动态的实例 上下文是程序运行所需要的各种状态，包括代码，数据，PC，运行栈等，程序在进程的上下文中运行

逻辑控制流

我们以单核处理器为例，假设某一时刻存在多个进程都需要运行，处理器在一个时间点上只能推进一个进程 处理器通过短暂，频繁地中断和切换其处理的进程，创造出一种所有进程都在同时进行的宏观表象

实际上，进程轮流占有处理器，执行一段时间后被抢占，其他进程进行处理。从宏观上来看，就好像每个进程都独占处理器，只是中间发生一些周期性的停顿

并发流

当两个进程运行的时间有交集时，就称这两个进程并发运行 当两个进程并发地运行在不同的处理器核心或者计算机上时，就称这两个进程并行运行 并发和并行最终都达到了多任务的结果

私有地址空间

操作系统通过为每个进程分配虚拟地址空间，使得宏观上就像每个进程占用整个系统地址空间

用户模式和内核模式

用户模式限制了应用可以执行的指令和访问的地址空间 在控制寄存器中，存在一位模式位，当这一位被设置时，进程就处于内核模式，可以执行任何指令集中的指令，访问内存中的任意空间 反之，进程处于用户模式，必须通过异常在异常处理程序中处于内核模式进行操作，然后再回到用户模式中 在linux中，/proc和/sys中存放了内核的信息，大部分只读，小部分可写

上下文切换

内核为每个进程都维护了一个上下文，当需要切换该进程执行时，恢复上下文并控制传递给这个进程即可 在进程执行时，内核中的一段称为调度器的代码进行调度的决策，即决定是否对某个正在执行的进程进行抢占，转而执行其他被挂起的进程 例如，当一个进程需要进行磁盘写的时候，调度器可以先上下文切换执行其他进程，当直接内存访问完成后再转而执行该进程 中断也可能引起上下文切换，如系统都能周期性地发出中断信号，让内核判定当前进程已经进行了较长时间，应该进行上下文切换

进程控制

下文介绍Linux下C程序中的进程控制方法

获取进程id

pid_t getpid();
pid_t getppid();

在Linux中，pid_t 被实现为 int。getpid返回当前进程的pid，getppid返回父进程的pid

创建和终止进程

void exit(int status);

exit函数直接终止当前进程，并将退出状态设置为status

pid_t fork();

fork创建一个子进程，该子进程被创建时几乎是父进程的一份拷贝，享有私有地址空间，与父进程并发地运行。当前进程为父进程的时候，返回值为创建的子进程的pid；当前进程为新的子进程的时候，返回值为0；由此可以判断当前执行的是子进程还是父进程。子进程与父进程交替执行的顺序未知，由调度器决定

同时在shell中，也可以为了对一行命令行求值创建进程，该进程被称为任务，shell为每个任务创建一个新的进程组 通过| (pipe) 将多个进程连接起来，如linux> ls | sort

子进程的回收

当一个进程终止时，其相关的部分状态会仍然保持在内核中，直到被回收。一个终止但未被回收的进程称为僵尸进程(zombie) 父进程可以对终止的子进程进行回收。当一个父进程终止，但是其子进程还没有被回收时，系统会安排pid为1的所有进程的祖先 init进程去回收它们，避免了对于系统资源的占用

pid_t waitpid(pid_t pid, int *statusp, int options);

该函数默认行为是将当前进程挂起，直到指定的子进程终止，然后将子进程回收，最后返回被回收的子进程的pid 若发生错误，则返回-1。错误原因为没有该子进程时，errno被设置为ECHILD；原因为该函数被信号中断时，设置为EINTR

其中，pid表明了需要等待回收的子进程id，若id=-1则为当前进程的全部子进程，否则为pid为该参数的子进程

options能指定该函数的行为，0为默认行为，可以通过以下定义的常量设置其行为

1. WNOHANG：当前进程不会被挂起，即只会检查pid是否终止，终止则返回pid，否则返回0
2. WUNTRACE：挂起当前进程，采取上文提到的默认行为，同时检查pid是否终止或挂起
3. WCONTINUED：挂起当前进程，采取上文提到的默认行为，同时检查pid是否终止或从挂起变为执行 以上的选项可以进行或运算(如(WNOHANG | WUNTRACE))，函数行为是两种行为逻辑上的或

在该函数调用完毕后，statusp指向的值会被改为导致子进程返回的信息，可以通过以下几个宏进行查看

也可以使用wait(int *statusp)函数，该函数等价于waitpid(-1, statusp, 0)

以下是waitpid的一个例子

父进程和子进程执行顺序未知，子进程可能尚未执行完exit函数，需要重复将父进程挂起等待然后回收终止的子进程

进程的休眠

unsigned int sleep(unsigned int secs);
int pause();

sleep将当前进程挂起secs秒，可能被信号中断，返回值为还剩余的秒数 pause会将当前进程一直挂起，直到收到一个信号

加载并运行程序

int execve(const char *filename, const char *argv[], const char *envp[])

该函数直接在当前进程中执行可执行文件filename，参数为argv，环境变量为envp，此后除非找不到filename才返回-1，否则不会返回 execve调用启动代码，将控制和相关参数传递给filename的main函数

linux下，C提供了getenv，setenv，unsetenv等函数对当前进程的环境变量进行修改

通过fork+execve，我们得以在创建的子进程中运行一个程序

信号

异常是处理器层面的，而信号可以理解为程序层面的异常。信号提供了一种机制，内核通知用户进程发生了异常，进程做出相应的反应 例如：shell 中 Ctrl+C使内核向前台进程组发送SIGINT信号请求终止；Ctrl+Z使内核发送SIGTSTP信号请求挂起

信号处理的流程

当一个系统事件发生时，内核会将对应的信号发送给相应的进程，该进程以某种方式对信号做出回应，称为接收了该信号

每个进程都有两个内核维护的信号集：pending未决信号集 和 blocked 阻塞信号集

当一个信号产生时：

1. 首先检查该信号在blocked集中的对应位：

   • 如果为1（被阻塞）：将pending集中对应位设为1，信号暂时不会被递送
   • 如果为0（未被阻塞）：立即尝试递送信号

2. 接收信号时：

   • 如果进程正在执行相同信号的处理程序，则将pending位设为1，等待当前处理完成
   • 否则，调用信号处理程序

3. 信号处理完成后：

   • 内核检查pending集，如果有被阻塞的信号变为未阻塞，则接收它们
   • 接收完成后，清除相应的pending位（设为0）

由于pending集采用位图实现，短时间内多次产生的相同信号：

• 在pending集中只会记录一次（位图只能为0或1）
• 即使产生了多次，也只会被接收一次 这就是"标准信号不排队"的现象（注意：实时信号是排队的）

发送信号

进程组

通过将每个进程都分配到某个进程组，得以实现对大量进程发送同一信号

pid_t getpgrp();
int setpgid(pid_t pid, pid_t pgid);

getpgrp 返回当前进程所在进程组编号；setpgid将pid进程所属的组设置为pgid，成功返回0，错误返回-1，pid为0时是当前进程，pgid为0时表示分配到以该进程pid为pgid的进程组

信号的发送

在shell中，可以使用linux>/bin/kill -SIG PID 向PID发送SIG对应的信号，其中若PID为负数，则对应的进程为PID绝对值对应的进程组号 在C中，也可以使用kill函数

int kill(pid_t pid, int sig);

用法与/bin/kill类似，只是两个参数位置相反，并且pid=0是是向当前进程所在组的所有进程发送该信号

unsigned int alarm(unsigned int secs);

在secs秒后，内核向当前进程发送一个SIGALRM信号，新的闹钟会取代旧的闹钟，并返回旧闹钟剩余时间

接收信号

C中可以通过signal函数改变除SIGSTOP，SIGKILL以外的信号对应的信号处理程序的行为，原型如下

typedef void (*sighandler_t)(int)
sighandler_t signal(int signum, sighandler_t handler);

该函数将signum对应的信号处理程序行为改为handler函数，若成功则返回之前的行为对应的函数，否则返回SIG_ERR

handler可以取以下参数：

1. SIG_IGN 将行为设置为忽略该信号
2. SIG_DFL将行为设置为默认行为
3. 传入一个自定义的函数，将行为设置为该函数

事实上，由于较老的Unix系统对信号的处理行为不同，signal函数可移植性比较差，而sigaction函数具有较好的可移植性，但是调用比较复杂。我们可以通过采用sigaction作为实现，定义与signal行为相同的函数

信号的阻塞

隐式阻塞机制：标准信号不排队，会被阻塞 显式阻塞机制：使用 sigprocmask对blocked位进行修改

注意：对blocked的修改，需要自己定义一个sigset_t的变量，通过sigfillset等函数对其进行构造，在将该变量作为参数传入sigprocmask中，实现对blocked的修改

信号处理程序的编写原则

信号处理程序与主程序并发运行，享用同样的全局变量，在编写的时候需要保持谨慎，遵守以下的保守原则

1. 信号处理程序要尽量简单，如只是设置标识符，将处理交给主函数
2. 采用异步信号安全的函数，这些函数不会被中断，或者是可重入的

3.运行前保存，运行后恢复errno：信号处理程序可能会修改errno的值，主函数中某些函数返回值可能与该值相关 4.对于所有的信号进行阻塞，然后再恢复原阻塞状态 5.使用sig_atomic_t和volatile定义全局变量，volatile告诉编译器该变量不稳定，不要放入寄存器中，而是直接内存访问，避免因为编译器过高的优化导致对该变量的行为改变；sig_atomic_t保证了该变量读写的原子性，即不会被中断 6.注意标准信号不排队机制：当内核检查到pending位为1时，可能已经接收了多个标准信号，需要对这些信号处理不止一次 例如以下的对SIGCHLD子进程终止的信号处理程序就使用while对信号进行多次处理，防止了僵尸进程

7.进行流同步：由于信号处理程序和主函数并发运行，当两者之间存在依赖关系时，如主函数先执行add操作，信号处理程序执行del操作，如果信号处理程序先执行，就可能出错，我们称之为发生了竞争。我们可以通过将对应的信号阻塞，当主函数执行完毕后，再取消阻塞，就保证了流同步

显式地等待信号

在shell执行前台任务时，会一直等待直到该任务结束，即收到SIGCHLD信号。我们假设信号处理函数会将pid设置为wait函数的返回值，可以写出以下代码

while (!pid) {

}
do something...

但是这段代码的缺陷是它大量执行了循环的判断，而不是子进程，这导致了处理器资源的浪费，考虑如下的代码

while (!pid) {
	pause();
}
do something...

看起来这段代码将当前进程挂起，直到收到了SIGCHLD信号。但是如果SIGCHLD信号在条件检查和pause之间发生，就可能丢失唤醒，导致一直被挂起，所以我们需要让“解除阻塞并等待”这个操作具有原子性。可以使用sigsuspend函数

int sigsuspend(const sigset_t *mask);

该函数暂时地将blocked设置为mask，并执行pause，结束后恢复原来的blocked，且该函数具有原子性

非本地跳转

C提供了一种用户级的异常控制流方式，称为非本地跳转，可以直接从一个正在执行的函数转移到另一个函数，使用setjmp，longjmp实现

#include <setjmp.h>

int setjmp(jmp_buf env);
int longjmp(jmp_buf env, int retval);

通过setjmp，将当前的调用环境放入env中并且返回0；调用longjmp，将控制转移到env被setjmp，调用环境也设置为与env中的相同，并使得转移位置的setjmp返回值为retval

注意setjmp不会保存pending和blocked

通过非本地跳转，我们得以实现嵌套函数的退出

通过sigsetjmp(env, savesigs)配合siglongjmp，我们可以在需要时保存并恢复信号屏蔽字blocked；未决信号集pending不会作为跳转环境保存

将各种代码和数据片段收集并组合成一个单一文件的过程称为链接 通过链接，我们得以将更小的，更易于管理调试的模块组合起来，形成大型程序，同时便于引入共享库，降低编码难度

链接概述

在shell中，使用linux>gcc -o prog main.c sum.c 调用编译器驱动程序，得到两个模块组合形成的程序prog 具体来说，从$.c$文件开始 1.预处理：驱动程序运行C预处理器(cpp)，对源代码进行替换(头文件包含，宏展开，条件编译#if #ifdef #endif...)，删除注释得到ASCII码的中间$.i$文件 2.编译：驱动程序运行C编译器(cc1)，将$.i$文件进行编译得到$.s$汇编语言文件 3.汇编：驱动程序运行汇编器(as)，将$.s$翻译成机器指令，得到可重定位文件 $.o$ 4.链接：驱动程序运行链接器将.o文件和必要的系统目标文件组合在一起，生成可执行文件 5.运行：使用linux>./prog 调用操作系统中的加载器，将指令和数据加载到内存中，并控制转移到这个程序的开头

静态链接

静态链接器由一组可重定位目标文件和命令行参数作为输入，生成完全链接的可执行文件 链接器完成以下两个任务： 1.符号解析：将一个符号和一个符号定义关联起来(是全局变量，静态变量，或者函数) 2.重定位：将每个符号定义与一个内存位置关联起来，然后修改所有对这些符号的引用，使它们指向这个内存位置 x86-64 linux使用可执行可链接格式(Executable and Linkable Format，ELF)作为目标文件的格式，下文以其为例

可重定位目标文件的格式

• ELF头：描述生成该ELF文件的系统的信息，以及该ELF文件的一些基本信息
• .text：已编译生成的机器代码
• .rodata：只读数据，如常量，printf输出的字符串等
• .data：被初始化的全局和静态变量
• .bss：未初始化的静态变量或初始化为0的全局和静态变量，这些变量运行时占用内存，但在目标文件中通常只记录大小而不占用实际数据字节
• .symtab：存放在该程序中定义和引用的全局变量，静态变量和函数的信息
• .rel.text .text部分中需要重定位的位置(引用的外部函数)
• .rel.data .data中需要被重定位的位置(引用的外部全局变量)
• .debug .line 编译选项-g得到的调试信息
• .strtab 存储.symtab和.debug中符号的一个字符串表

符号的类型

symtab包含以下三种符号：

1. 全局符号：由该模块定义，并被其他程序引用的符号
2. 外部符号：由其他模块定义，在该程序中被引用的符号
3. 局部符号：在该模块中定义的静态函数和变量(static)

本地变量不会包含在symtab中，而是会在运行栈中被管理；而使用static的符号虽然在symtab中，但是是该模块私有的，不会被其他模块引用

symtab的构成

symtab中包含多个符号，每个符号用一个如下结构的条目表示

• name：该条目符号在.strtab中的偏移量，从.strtab中这个位置开始一直取字符直到遇到结束符
• type：该符号为函数还是变量
• binding：该符号是在该模块中定义的还是从外部引用的
• section：表明该符号属于哪一节
• value：该符号相对于其所在节的地址偏移量
• size：该符号的字节大小

注意section字段指明了该符号属于哪一节，但除了.data，.text，.bss，.rodata外，它还可能指向三个在ELF中不存在的伪节 1.ABS表示该符号不应该被重定位 2.UNDEF表示在该模块中未定义，即从外部模块引用的符号 3.COMMON表示未初始化的全局变量的试探性定义；对比.bss通常保存未初始化的静态变量以及初始化为0的全局和静态变量

我们可以使用GNU READELF程序查看目标文件内容，一个示例如下

符号解析

强符号：函数和已初始化的全局变量 弱符号：未初始化的全局变量 不难发现，对于变量来说，弱符号都被分配到COMMON节

链接器使用以下规则处理多重定义的符号：

1. 不允许有多个同名的强符号
2. 如果有一个强符号和多个弱符号同名，选择强符号
3. 如果有多个弱符号同名，任意选择一个

以下是一个由该规则可能导致的错误

两个模块中，第一个x是强符号，而第二个是COMMON，链接器将它们合并，并按较大的对象大小分配存储，那么对 x 的写入可能覆盖相邻数据，例如修改到 y

在C中，可以使用gcc -fno-common这样的选项，让链接器在遇到多重定义的全局符号时报错；而在C++中不支持COMMON，相当于默认使用该行为

与静态库链接

静态库是相关目标文件(.o文件)的集合，以存档格式(.a文件)存储，链接静态库时，链接器只复制被程序引用的目标模块 使用AR工具，可以创建函数的一个静态库 linux> gcc -c addvec.c multvec.c linux> ar rcs libvector.a addvec.o multvec.o 要使用这个静态库，我们直接在main.c中加入#include "vector.h"即可调用addvec，multvec这两个函数(无需声明原型) 然后再使用-static使链接器进行静态链接 linux> gcc -c main.c linux> gcc -static -o prog main.o ./libvector.a

链接器静态链接的行为

对于输入文件，链接器按输入顺序从左到右扫描 若当前文件是一个.o目标文件，链接器会无条件把它加入链接，并用其中的定义更新已定义符号集合和未解析符号集合 若当前文件是一个.a存档文件，链接器会扫描其中的目标模块；只有某个成员定义了当前未解析的符号时，才会把该成员加入链接，并继续更新符号集合 结束后，若集合不为空，链接器报错；否则执行合并与重定位，生成可执行文件

由该过程可见，链接存在依赖关系，符号应该先引用，后定义；同时链接器支持重复库，即同一个库多次输入在可以在链接器中不同位置

重定位

完成符号解析后，链接器进行重定位，包含两个关键步骤：

1. 合并输入模块得到聚合节，并为每个聚合节和其中的符号分配运行时内存地址
2. 根据重定位条目，修改每个符号的引用，使它们指向正确的运行时地址

重定位条目

重定位条目存在于.rel.data和.rel.text中，作用是告知链接器如何对于一个外部符号进行修改，其结构如下

重定位的算法描述如下

为了便于理解，我们直接举下面的例子

注意：linux x86-64使用小端序！！！ array是一个外部变量，我们想要将它的地址作为参数传入%edi中，但是由于地址未知，所以32位都用0来填充，并在这里留下一个类型为R_X86_64_32的重定位条目，表示进行32位绝对重定位。该条目的offset偏移值为$0xa$，即重定位会从该偏移值开始填充32位，addend为0（结构体访问成员时可能不为0）。refptr指向这段填充的0的起始位置，然后将从这个位置开始的4个字节赋为该符号分配的地址的值，得到array的正确地址，并传入sum函数作为参数

同样由于sum的具体代码的内存地址未知，使用0填充并留下一个类型为R_X86_64_PC32的重定位条目，表示进行32位相对重定位(因为call 一般使用相对寻址)，当执行call时，PC指向下一条指令的开头，即PC增加了4，为了补偿这个增量，我们将addend设置为-4，refptr指向这段填充的0的起始位置，然后计算.text聚合节中分配运行内存后，sum函数相对于.text的地址偏移量，并加上addend作为补偿，得到的就是在分配的内存中PC跳转到sum需要的地址偏移量，将这个值存入refptr指向的后4个字节中。当调用sum函数时，PC的值增加这个偏移量，刚好是sum函数的第一条指令

经过重定位，最后得到可执行目标文件

可执行目标文件

ELF可执行文件被设计为易于加载到内存，格式如下：

• ELF头部：描述文件的总体格式，包括程序入口点（entry point）
• 段头部表：描述可执行文件中的片（segment）到内存段的映射关系
• .init：定义初始化代码
• .text、.rodata、.data、.bss：程序代码和数据
• 其他节：如.symtab、.debug等

可执行文件通过加载器映射到内存中并运行：

1. 创建进程和地址空间
2. 将可执行文件的片（segment）映射到相应的虚拟内存区域，必要时按需调页载入
3. 跳转到程序的入口点（通常是_start）

在Linux x86-64系统中，程序入口点不是main函数，而是_start函数，它调用__libc_start_main，后者再调用main函数

运行时的内存分配情况如下：

动态链接

共享库是一个目标模块，该模块在运行的时候可以加载到任意地址，和一个内存中的程序链接起来，该过程称为动态链接 该技术节省了空间，不需要在编译时将库中相应的文件链接过来，而是在运行前或运行中才进行链接；同时也方便了库的更新，不需要每次更新库的时候都对目标文件重新链接

在linux下，动态库文件扩展名为.so，windows中为.dll

linux> gcc -shared -fpic -o libvector.so addvec.c multvec.c linux> gcc -o prog main.c ./libvector.so 得到在运行时，可以与libvector.so进行动态链接的可执行文件prog

动态链接的过程

首先，执行一次静态的链接，生成的部分链接的可执行文件中含有共享库中的重定位和符号表信息，但是没有符号具体的定义 在执行这个部分链接的可执行文件前或运行中，动态链接器动态地将共享库中符号具体定义链接进来，内存中即为完全链接的可执行文件

linux系统提供了相关的程序接口dlopen()、dlsym()、dlclose()、dlerror()，可以在程序运行中进行动态链接

位置无关代码

咕咕咕

库打桩机制

打桩允许我们截获对共享库函数的调用，取而代之执行自己的代码，这对于调试大型项目时极其有效

打桩可以在三个不同的阶段进行：

1. 编译时打桩

例如，为了对于程

gcc -DCOMPILETIME -c mymalloc.c
gcc -I. -o prog main.c mymalloc.o

1. 链接时打桩

gcc -DLINKTIME -c mymalloc.c
gcc -c main.c
gcc -Wl,--wrap,malloc -Wl,--wrap,free -o prog main.o mymalloc.o

1. 运行时打桩

#define _GNU_SOURCE
#include <dlfcn.h>

void *malloc(size_t size) {
    void *(*mallocp)(size_t size);
    char *error;
    
    mallocp = dlsym(RTLD_NEXT, "malloc"); // 获取libc的malloc
    // ... 打桩代码 ...
    return (*mallocp)(size);
}

这一章看下来真的太难受了（（（

存储器系统是一个具有不同容量，成本和访问时间的存储设备的层次系统 整体效果是一个大的储存器池，但却以接近最便宜存储设备的成本，做到了接近顶层存储设备的读写效率 存储器层次由快到慢分别为寄存器，高速缓存存储器，主存储器，本地二级存储器，远程二级存储器

存储技术

RAM

随机访问存储器(Random Access Memory)可分为DRAM(Dynamic)和SRAM(Static)两类 SRAM 使用六晶体管电路实现，具有双稳态性，只要有电就会保持它的值，在干扰结束时，也会回到稳定状态 DRAM 对干扰十分敏感，易漏电，必须周期性刷新以保持数据；纠错码可以检测或纠正部分位错误，但不能替代刷新

DRAM的读写

每个DRAM单元存储一位信息，$w$个DRAM单元组成一个超单元，再由$d$个超单元组成一个DRAM芯片 $d$个超单元构成一个$r \times c$的二维阵列，每个超单元有由行列构成的二元组地址$(i, j)$ DRAM芯片通过地址引脚和数据引脚与外部传递信息，通过两次在地址引脚上传入行地址和列地址来确定要读写的超单元，再通过数据引脚传递具体数据。将超单元设计为二维，减少了需要的地址引脚个数，代价是地址需要分两次传入，降低了效率

内存模块

内存模块中封装了多个DRAM芯片，我们以8个8M的DRAM芯片，每个超单元存储1个字节为例 当需要访问一个地址为A的字的时候，内存控制器将A翻译成超单元地址$(i,j)$并发送到内存模块中，内存模块再将$(i,j)$广播到每一个DRAM芯片，8个芯片都取出它地址为$(i,j)$的超单元中存储的字节，再将这八个字节合并起来，传送到内存控制器中 将一个字存储在不同的DRAM芯片内的好处：通过提高并行性提高了访问效率，同时减少整个字丢失的可能，提高了可靠性

ROM

只读存储器(Read Only Memory) 部分的ROM读写都支持，但是所有的ROM都是非易失性的

PROM (Programmable ROM) 可编程ROM只能使用高电流编程一次 EPROM(Erasable PROM) 可擦写可编程ROM 与 EEPROM(Electrically EPROM) 电子可擦除ROM都能使用特殊手段擦除数据重新编程，但次数有限 flash memory 闪存基于EEPROM，如固态硬盘

ROM中的程序被称为固件(firmware)，在通电下运行，如PC的BIOS

主存的访问

数据流通过总线(bus)在处理器和主存之间传送，读事务中数据从主存传送到处理器，写事务中数据从处理器传送到主存 处理器通过系统总线与I/O桥接器连接，主存通过内存总线与I/O桥接器连接，I/O桥接器通过将系统总线和内存总线传入的信号进行翻译 同时，I/O桥接器还连接了I/O总线，我们会在下文提到 以读事务为例

磁盘的存储

磁盘的构造

每个磁盘包含了一个或多个盘片，每个盘片有着两个盘面，盘片绕着中心的主轴，以固定的角速度旋转 每个盘片包含了多个被称为磁道的同心圆，每个磁道上都有着多个用来存储信息的扇区，每个扇区存储的信息量大小相同，扇区间由用来标记格式化位的间隙分开 我们用柱面称呼到主轴间距相等的磁道构成的集合

磁盘的存储

磁盘存储的信息量取决于面密度，即单位面积内可存储的位数；它通常由磁道密度和每条磁道上的线性位密度共同决定

为了简化控制，磁道的扇区数需要尽量保持相等 在技术不发达，面密度比较低的时期，每个磁道的扇区数完全相同，这导致外围的扇区间隙相比内围大了很多，造成了不必要的浪费 现代磁盘使用多区记录的技术，在每个记录区中保存了一段连续的柱面，每个记录区中的磁道扇区数相同，记录区间的扇区数不同。通过多区记录，达到了存储空间和控制难度的平衡

为什么标注1TB大小的硬盘电脑显示只有931GB？ 这是制造商使用的十进制（$1TB = 1000^4$ 字节）与操作系统使用的二进制（$1TiB = 1024^4$ 字节 $\approx 931GiB$）之间的差异。

磁盘的读写

磁盘中的读/写头连接到外围的传动臂上，通过绕着传动臂转动，进行寻道以定位到某个给定的磁道上，当磁道上的某个扇区旋转到读写头正下方时，就可以对其进行读写操作

对一个扇区的访问时间，取决于一下三个部分： 1.寻道时间：传动臂将读写头移动到指定磁道的时间，这个值取决于读写头之前的位置和传动臂移动的速度 2.旋转时间：等待需要操作的扇区旋转到读写头的正下方，这取决于盘片旋转的角速度和此时目标扇区的位置 3.传送时间：这个扇区从头到尾经过读写头需要的时间，这取决于盘片旋转的角速度

计算的一个示例

可见读写的时间主要取决于寻道时间和旋转时间

磁盘经过封装得到硬盘驱动器，简称硬盘，“硬盘”一词不加修饰时，通常指基于磁盘技术的机械硬盘（Hard Disk Drive, HDD），但需注意与固态硬盘（SSD）区分

逻辑磁盘块

在逻辑上，我们可以将扇区看成一个大小为$B$的单元结构，使用一个逻辑块号进行寻址，磁盘控制器从操作系统接收这个逻辑块号，将其翻译成一个(盘面，磁道，扇区)的三元组，再对其进行寻址并进行操作

IO设备的连接

现代计算机系统使用PCIe（Peripheral Component Interconnect Express）总线作为主要的I/O总线标准，它取代了早期的PCI总线，将包括键鼠，图形卡，磁盘等在内的I/O设备连接到CPU和主存 有几种不同的IO设备使用I/O总线连接 1.外围I/O设备如键鼠，固态硬盘，打印机等通过通用串行总线(Universal Serial Bus,USB)连接到USB控制器 2.图形卡(由GPU显卡，散热器，PCB板等组成) 3.机械磁盘通过SCSI(更快更贵)或者SATA接口连接到主机总线适配器，从而连接到I/O总线 4.其他设备如网络适配器等通过主板上的拓展槽连接到I/O总线中

CPU与IO设备的交互

CPU通过特定的地址与I/O设备通信。这些地址可能属于独立的I/O端口地址空间，也可能被映射到物理内存地址空间中（称为内存映射I/O） 以磁盘读为例，CPU向磁盘对应的I/O端口发出三条指令，分别是指令字，逻辑块号，存放在主存中的地址 磁盘控制器接收这些信号翻译得到扇区地址，读扇区后无需CPU干涉直接将数据传输到主存，这称为直接内存访问(Direct Memory Access DMA) 磁盘读取的时间远远大于处理器执行其它指令的时间，通过直接内存访问，避免了CPU的等待 DMA传送完成后，磁盘控制器向CPU发送一个中断信号，处理器转入相应的中断处理程序记录I/O操作已经完成，随后再恢复被中断的控制流

固态硬盘

固态硬盘(Solid State Disk, SSD)封装在I/O总线的插槽上(计算机内部)，采用闪存技术，一个SSD封装由一个或多个闪存芯片和一个闪存翻译器构成，其中 闪存芯片功能上类似于机械磁盘的机械驱动器，而闪存翻译器则类似于磁盘控制器

一个闪存由B个块构成，每个块内又有P个页，只有当一个页所在的块被擦除(所有位都被设置为1)才能对该页进行写，这导致SSD写的效率低于读。同时由于闪存基于EEPROM，所以写入次数有限，现代SSD采用了复杂的逻辑，减小了擦写块的时间代价，以及尝试让块的擦写尽量均匀，增加了SSD的寿命

SSD价格上比机械硬盘稍贵，并且写入次数有限，但是SSD读写速度远高于机械硬盘，并且随着SSD越来越受欢迎，其与机械硬盘价格差距也越来越小

局部性

数据的局部性

对内存层次中较低层的访问代价很高，所以局部性通常是影响程序性能的重要因素之一

良好的时间局部性：一个内存位置被引用后，不久之后被再次引用 良好的空间局部性：一个内存位置被引用后，不久之后其附近的位置被再次引用

例如考虑以下代码：

int sum = 0;
for (int i = 1; i <= n; i++) {
	for (int j = 1; j <= n; j++) {
		sum += a[i][j];
	}
}

sum = 0;
for (int j = 1; j <= n; j++) {
	for (int i = 1; i <= n; i++) {
		sum += a[i][j];
	}
}

第一段循环局部性明显优于第二段，因为第一段按引用步长为1访问数组，而第二段按引用步长为n访问数组

指令的局部性

指令也是存储在内存中的，按照内存顺序执行的指令有着良好的局部性，往往循环体越小，循环迭代次数越多，局部性越好

高速缓存

缓存的基本原理

缓存的概念

存储器的每一层都是下一层更大更慢存储器中数据的一个缓冲空间，该过程被称为缓存

相邻的两层会以相同大小的块作为传输单位，更上层的存储器维护的是更底层存储器中若干块的副本，数据以块为基本单位在两层之间传输。不相邻层次块的大小可能不同

缓存访问概述

1.缓存命中：当需要访问第$k+1$层中块号为$A$的数据时，先在第$k$层中查找是否保存了该数据，如果存在直接高效访问即可，我们称之为缓存命中

2.缓存不命中：当第$k$层中没有该数据时，就从第$k+1$层读出$A$号块。若能采用某种放置策略，将$A$号块放入一个空块，则就这样放置并访问；否则采取某种替换策略，用$A$号块替换$k$中某个块并访问

3.放置策略与替换策略：为了降低采用策略的代价，这两种策略一般都比较简单。如放置策略就采取简单地将$k+1$层中的每个块都放入在$k$层映射所对应的块中(如对块编号取模得到的数对应的块)，替换策略采用随机替换，最不常使用替换，最近最少使用替换等策略

4.缓存不命中的种类：第一次访问某个块时，缓存中必然没有它，我们称之为冷不命中；当放置策略使多个常用块竞争同一组时，可能导致冲突不命中，如只有4个组的直接映射缓存反复访问第0、4、0、4......号块，缓存就会一直不命中；当需要访问的数据构成的工作集太大，大于缓存能容纳的块数时发生的缓存不命中，称为容量不命中

5.缓存的管理：管理缓存的逻辑可以是硬件，软件，或者是两者的结合

缓存的结构

现代计算机采用了L1，L2，L3三层缓存，为了方便起见，我们简化为只有L1缓存

缓存的通用结构

以在一个m位的系统中进行缓存$k$级读为例

对于一个高速缓存，我们将其分为$S=2^s$个组，每个组内有$E$行，每一行有着一个1位的有效位，$t$位的标记位，以及$B=2^b$个字节的数据块，下标分别为$0, 1, \ldots, B-1$，我们称缓存的数据容量为$C = B \times E \times S$

我们该系统地址有m位，即有$M=2^m$个地址，那么我们用会通过一个长$m$位的数$A$来确定访问的地址 考虑将这个$A$分成三个部分，分别是前$t$位作为标记，中间$s$位作为组索引，最后$b$位作为字节偏移值，满足$m=t+s+b$

通过组索引定位到缓存中的某一组，再并行地与组中的每一行进行比较，当这一行有效位为1且标记和标记位相等时，以字节偏移值为下标读出的这个字节就是需要读出的值

否则每一行都是有效位为0或和标记位不相等，这说明需要读的数不在$k$级缓存中，从$k+1$中重复该步骤，尝试读出该地址的值，在$k$级缓存中进行放入或者替换即可

本质上是地址到一个能唯一确定某个块的三元组的映射，但是完美利用了二进制的性质，发明这个的人真的是天才，计组真的太美了（

补充：为什么不使用更自然的高s位作为组索引，中间t位作为标记，后b位作为偏移值？ 若采用高s位为组索引，那么以连续访问地址为0到$2^{t+b}-1$的数据为例，这些数全都被分到了第一组，没有利用了其它组的，会多次发生缓存不命中，局部性良好的代码反而因此效率降低

缓存的各种类型

1.直接映射高速缓存：取 $E=1$，即每组只有一行，此时因为只有一行，替换策略极度简化，直接将新的数据块放入该行即可 2.全相联高速缓存：取$E = \frac{C}{B}$，即只有一组，故可以舍去组索引位，理论上可以对每一行并行判断，但是行数过多，成本昂贵，只适合规模小的高速缓存 3.组相联高速缓存：取 $1 < E < \frac{C}{B}$，即有多个组，每组有多个行，可以在组内并行地判断每一行，同时采取随机替换，最不常使用，最近最少使用等替换策略

缓存写

当需要进行写操作时，若对应地址在$k$级缓存中，即缓存命中，则有以下两种方法： 1.直写：同时更新第$k$层和第$k+1$层中的副本。该方法实现简单，但会增加下层访问流量 2.回写：类似于惰性删除，每一行维护一个初始为0的修改位，写的时候只在第$k$层进行写并将修改位设置为1，直到该行要被替换的时候再将修改后的块写回第$k+1$层。该方法减少了下层写流量，但实现更复杂 当缓存不命中时，同样有两种方法： 1.写分配：从第$k+1$层读入包含写地址的块到第$k$层，再在第$k$层执行写操作，常与回写搭配 2.非写分配：不把该块载入第$k$层，而是直接把写操作传递给第$k+1$层，常与直写搭配

实际的缓存结构

高速缓存既保存数据(d-cache)，又保存指令(i-cache)，也有数据和指令都保存的统一高速缓存，由于d-cache读写都需要，而i-cache只读，所以分开设计，采用不同的访问模式来优化这两种缓存

影响缓存效率的因素

1.高速缓存的大小：增大某一层缓存的大小，可以提高缓存命中率，但是每次缓存访问的时间会增加 2.缓存块大小的影响：在缓存容量固定的情况下，增大块的大小会导致行数减少。在空间局部性优秀的情况下会减少缓存不命中的概率，但是更大的块导致了单次拷贝消耗时间更长，缓存不命中的时候惩罚更大 3.相联度(一组内的行数)：相联度增大后，更不容易发生冲突不命中，但是增加了标记位的位数，以及需要采用更合理的逻辑选择替换行，成本也会增加

高速缓存友好的代码

引用步长的影响

假设缓存的块大小为$B$字节，对于一个引用步长为$k$的循环，每次迭代的平均缓存不命中次数为$\min(1, \frac{wordsize \times k}{B})$ 理解为缓存中最多存放$\frac{B}{wordsize}$个字，所以每$\frac{B}{wordsize \times k}$次循环就会出现缓存不命中，即每次迭代平均不命中$\frac{wordsize \times k}{B}$次 由此可知，取步长$k=1$对于缓存来说命中率最高

重新排列循环变量

我们以矩阵乘法的六种循环顺序为例

判断程序的性能，我们往往只需要关注最内层循环体的效率，可以先定性地来看 ijk和jik对A数组采用步长为1的访问，对B数组采用步长为n的访问 jki和kji对A数组和C数组都采用了步长为n的访问 kij和ikj对B数组和C数组都采用了步长为1的访问 所以可以得出结论：kij和ikj访问缓存效率最高，ijk和jik次之，jki和kji最差

定量地来看，我们假设缓存可以存放4个double，计算得到的效率表如下，这也印证了我们的分析

使用分块技术

当工作集大于缓存大小的时候，可以通过将工作集划分为多个块，块的大小不大于缓存的大小，能被完全放入缓存当中，高效地对这个块进行访问之后，丢掉这个块，继续载入访问下一个块

程序剖析

linux下可以使用$GPROF$定量衡量程序中函数的运行时间

在编译的时候，使用linux> gcc -Og -pg test.c -o test，避免优化导致剖析失真，得到为剖析而编译和链接的可执行文件 linux> ./test会运行该文件并生成gmon.out的相关数据文件，通过linux> gprof test进行分析

从左到右的每一列分别为函数运行时间占比，总累积运行时间，当前函数累积运行时间，被调用次数，每次调用平均运行时间

程序优化的基本原则

1.选用合适的算法与数据结构 2.以编译器更容易优化的形式编写程序 3.将一个任务分成多个部分，并行地计算

编译器级别的优化

指定优化等级

以GCC为例，编译时命令行选项从-Og -O1 -O2 -O3优化等级逐步提高，编译器会在行为一致的情况下，对程序进行安全的优化

函数内联优化

当使用-O1以及更高的优化或者-finline的时候，编译器会使用内联函数替换来减少函数的调用 例：

int cnt = 0;
int f() {
	return cnt++;
}
int f1() {
	return f() + f() + f() + f();
}

采用循环展开后，会被优化为

int f1() {
	int ret = cnt * 4 + 6;
	cnt += 4;
	return ret;
}

编译器级别优化的局限性

编译器对于程序只使用安全的优化，在有内存别名使用 (两个指针指向同一个地址)或者全局变量修改时，一些激进的优化可能导致程序行为发生改变，编译器不会采用这些优化

void f1(int *p1, int *p2) {
	*p1 += *p2;
	*p1 += *p2;
}

void f2(int *p1, int *p2) {
	*p1 += 2 * *p2;
}

在p1,p2指向同一个地址时，若初始值为$x$，f1会先变为$2x$再变为$4x$，而f2会变为$3x$

int cnt = 0;
int f() {
	return cnt++;
}
int f1() {
	return f() + f() + f() + f();
}
int f2() {
	return 4 * f();
}

编译器无法判断f函数是否会对全局变量造成影响，所以为了保证正确性，不会将f1优化为f2 可见编译器只会进行最基本的优化，我们需要通过改变编写程序的方式来激发其性能

程序的性能

程序性能的衡量

程序的效率 CPE：Cycles Per Element 每元素周期数 其中的元素为程序处理的基本数据单元，可以是一个整数，也可能是字符，像素等 显然CPE越小，程序越高效

对现代处理器的理解

处理器的效率用其时钟频率决定，通用单位为千兆赫兹GHZ，即十亿周期每秒 现代处理器通过乱序处理实现指令级并行，即多条指令可以并行地执行，但同时又呈现出顺序执行的表象 更具体地说，现代处理器中有多个功能单元，不同功能单元被设计处理不同的操作，以下是一个例子

处理器为了乱序执行的正确性，会在一条指令的所有源操作数都准备就绪，且所需要的功能单元有空闲的时候，将其用调度器发送出去并执行 因此，指令的执行顺序与程序顺序无绝对关系，而与数据就绪时间有关

功能单元的性能

延迟：完成一个运算所需要的总时钟周期 发射时间：两个同类型的运算间需要间隔的最小时钟周期。当发射时间为1时，我们称该功能单元运算完全流水化，即该运算的每个阶段逻辑上独立 容量：能执行该运算的功能单元数量 最大吞吐量：发射时间的倒数

延迟界限给出了单个操作CPE的下界，而吞吐量界限给出的是处理一系列操作时CPE的下界

如整数乘法只有一个乘法单元，故吞吐量界限为1 整数加法虽然有四个加法单元，但是受限于只有两个加载单元，导致每个时钟周期最多取两个数据，所以吞吐量界限为0.5

代码级别的优化

以下代码以数组变量累积为例，给出最原始的版本

减少重复的运算和调用

代码移动

由于循环没有对向量内容进行修改，我们可以提前保存向量的长度这个值，避免反复调用函数造成不必要的开销 该技巧被称为代码移动，因为编译器无法确认函数内部是否会对全局状态造成影响，所以默认不会优化 致敬某传奇OI教练在当年重邮打ACM时候写出的for (int i = 1; i <= strlen(s); i++)

保存常量

在$get_vec_element$函数内部，有边界检查，因为循环确保了不会出现数组越界，我们可以直接用数组下标访问元素，减少了过程调用 但是实际上这段代码数组越界与否，是高度可预测的，所以性能并没有产生显著的提升

减少内存引用

我们可以使用局部变量保存累积运算的结果，在循环结束的时候再将该值赋给*dest 有意思的是，程序性能却提高了2-5倍，有了极为显著的提升 修改后的C代码如下

优化前后代码编译生成的汇编代码如下

可以发现，优化后的代码通过将局部变量存放在寄存器中，避免了对于指针指向内存的频繁访问与写回 同样的，因为指针可能指向向量中的元素，这种情况下优化前后的两段代码运行结果存在差异，所以编译器不会进行优化

循环展开

对于一个循环，按任意因子$k$进行循环展开，称为$k \times 1$循环展开 以下是源代码$2\times1$循环展开后得到的代码

循环展开减少了循环开销操作，即减少了对于条件判断和循环变量增加的次数进而提高性能 但是提升有限，因为循环运行时间的瓶颈往往在循环内的操作，而非循环本身

提高并行性

使用多个累积变量

我们可以将一组运算分割成两个或者更多个部分，最后进行合并得到结果，我们将循环展开$k$次，并用$k$个变量记录累积值，称为$k \times k$循环展开

在设置累积变量后，程序性能有了显著的提高，甚至打破了延迟界限 通过累积变量，我们将单个寄存器参与运算变成了多个寄存器都参与运算，减少了数据相关 更进一步地，对于延迟为$L$，容量为$C$的操作来说，在循环展开因子$k \geq L \times C$，同时又不过大导致寄存器溢出(所需寄存器过多，导致处理器将局部变量存放在内存上，反而降低了性能)时，执行该操作的功能单元流水线能被填满 理解：取$k=L \times C$，每个时钟周期会启动$C$个操作，经过$L$个时钟周期后，最先被启动的前$C$个操作已经完成，不会再有数据依赖，刚好可以zai在下一轮循环开始时直接无依赖地启动前$C$个操作

注意：对无符号整数或按补码位模式理解的整数加法和乘法，采用多个累积变量与不采用累积变量只循环展开在模$2^w$意义下是等价的；但C语言中的有符号整数溢出是未定义行为，浮点数也会因为舍入和溢出而不满足这种等价

重新结合变换

我们将acc = acc OP data[i] OP data[i + 1]; 改为acc = acc OP (data[i] OP data[i + 1]); 发现其$CPE$与$2\times2$循环展开相当 简单来说，第一种实现将两次运算连续作用与acc,构成了一条更长的依赖链；而第二种实现先对两个数据运算后，再与acc进行运算，拆分成了两个可以并行的短链，减少了对于同一个寄存器的连续修改

使用向量指令

SIMD：单指令多数据，用单条指令对整个向量进行操作 流SIMD扩展(SSE)以及后续的AVX，可以对向量寄存器中的多个数据元素并行地进行运算；以256位AVX寄存器为例，一次可容纳8个32位元素或4个64位元素

Linux文件本质上是一个包含字节的序列，I/O设备都被模型化为文件，内核通过使用 Unix I/O这一接口，对文件进行操作

文件的类型

Linux目录层次构成的是一个树形结构，根节点为 / 根目录

此处介绍三种最常见的文件

1. 普通文件：分为文本文件和二进制文件。前者只含有 ASCII 和 Unicode 字符，采用LF格式，每一行以 '\n'结束；后者是其余的普通文件
2. 目录：目录是存储了一组文件名到文件的映射的文件，存储的映射可以是一个目录。用.表示到自身的映射，..表示到父节点的映射
3. 套接字：与另一个进程进行跨网络通信的文件

文件的打开关闭

open函数实现了打开或新建一个文件

open函数打开文件filename，采用flags的访问方式，当创建一个新文件时，mode参数指明了它的访问权限位

flags参数的取值可以如下： O_RDONLY O_WRONLY O_RDWR 分别表示只读，只写，同时读写 同时，还可以与以下值进行或运算： O_CREAT O_TRUNC O_APPEND 分别表示文件不存在时创建，将当前文件截断为空，写改为在当前文件末尾追加

每个进程都有一个umask变量，可通过umask函数设置，当使用mode创建一个新文件时，它的权限为mode & ~umask mode和umask的取值可以如下，同样支持或运算

open函数的返回值为一个整数的文件描述符。每个进程通常都会打开三个文件STDIN_FILENO，STDOUT_FILENO，STDERR_FILENO，文件描述符分别为0，1，2

使用close函数，传入一个文件的描述符，就可以关闭该文件

文件的读写

其中，fd为对应文件的描述符，buf为从文件读的数据存放到的地址指针或要写入文件的数据的地址指针，n为最大读写字节数 值得注意的是，当能读的字节数小于要求的字节数n时，会读取剩下的所有字节，然后将文件读对应的指针指向文件的末尾

RIO包实现健壮的读写

当遇到EOF或者进行网络通信时，读写操作的字节数会比要求的要少，此时称产生了不足值。在网络编程中，我们需要处理这种不足值避免出错，所以需要实现一个RIO(Robust I/O)包

无缓冲的输入输出函数

直接在内存和文件之间传输数据，没有应用级缓冲

原型如下

实现如下，输入函数会在被信号中断后继续进行，使用了while循环反复调用read函数直到读入要求的字节数，除非遇到了EOF；输出函数类似

带缓冲的输入函数

先将从文件读的数据放入一个缓冲区内，当调用函数时，尝试从该缓冲区内读取数据，这样避免了反复系统调用read函数。例如检查是否换行时，我们需要调用字符串长次read函数，每次读入1字节，这样会反复进入内核。而采用带缓冲的输入，可以一次调用read读入多个字节，再遍历缓冲区检查是否有换行即可

函数原型如下

具体实现如下

读取文件信息

文件的信息，也称为文件的元数据

目录的读取

使用 opendir打开一个目录

注意opendir返回的是一个DIR *目录流指针；readdir返回的目录项是struct dirent *，该结构体定义如下

使用readdir读取下一个目录项

使用closedir关闭一个目录

共享文件

每个进程维护了一个描述符表，每个打开文件的操作与其中描述符相同的表项对应，每个表目都指向了打开文件表的一个表项。打开文件表由所有进程共享，它存储了一个被打开文件的打开次数和位置，并指向由所有进程共享的，存放了当前文件元数据的v-node表的对应表项

当执行fork时，子进程也会复制父进程的描述符表

I/O重定向

考虑shell中的指令linux> ls > foo.txt，实现了将ls指令的结果标准输出重定向到foo.txt中 对应的 dup2用户级调用原型如下，实现了oldfd描述表表项对newfd表项的覆盖

以dup2(4,1)为例，实现了对描述符为1的STDOUT标准输出的重定向，重定向到了描述符为4的打开操作对应的文件

I/O函数的使用

C也提供了被称为标准I/O库的高级输入输出函数，通过FILE这一类型实现了对文件描述符和流缓冲区的抽象

在大多数情况下，我们会使用标准I/O库；当涉及二进制文件时，不应该使用scanf和rio_readlineb；当涉及网络编程时，一般需要使用RIO函数

虚拟地址这一机制为每个进程提供了独立的，私有的地址空间，简化了内存的管理，同时也避免了进程的地址空间被其它进程破坏

物理寻址和虚拟寻址

主存(DRAM实现)可以看做一个由$M$个字节组成的数组(不一定连续，中间可能有内存映射I/O区域)，通过数组索引访问内存的方式称为物理寻址(故主存也可称物理内存)，一般用于嵌入式

CPU通过生成的虚拟地址，在处理器芯片上通过内存管理单元MMU进行地址翻译，得到对应的物理地址，再根据此对主存进行访问，称为虚拟寻址

对于一个n位线性地址空间，可以访问的地址为$0$到$2^n-1$ $n$位地址理论上最多表示$2^n$个不同地址；实际CPU支持的虚拟地址位数常小于寄存器位宽。现代操作系统提供的虚拟地址空间通常大于实际物理内存容量

虚拟内存与缓存

虚拟内存在实体上并不存在，虚拟地址只是用来访问物理地址的一个抽象值

虚拟内存被分割为虚拟页，每个虚拟页都是固定大小的连续虚拟地址的集合。物理页同理，且每页大小和虚拟页相同，便于实现虚拟页到物理页的映射，将物理页与虚拟页关联起来

通过虚拟内存这一机制，我们得以实现从磁盘到主存的缓存机制 虚拟页中每一页可能有如下三种情况：

1. 未分配的：该页还没有和磁盘上的某部分相关联
2. 未缓存的：该页已经和磁盘上的某部分相关联，但是这些磁盘信息还没有缓存到主存中，所以这一页也没有对应一个物理页
3. 已缓存的：该页已经和磁盘上的某部分相关联，且这些磁盘信息正在主存中，这一页已经对应了一个物理页

类比SRAM实现的高速缓存，主存也会发生替换，由于主存不命中的惩罚大的多(从磁盘中读取数据特别慢)，主存DRAM是全相连的，使用了更精细的替换算法，同时采用写回而不是直写

物理内存缓存的机制

页表

为了明确某个虚拟页处于以上三种情况的哪一种，我们引入了页表这一数据结构 每个进程都有一个页表，存储在物理内存中，是用来存储页表条目(Page Table Entry，PTE)的一个数组 对于编号为$k$的虚拟页，编号为$k$的页表条目存储了其状态信息 页表条目存储的信息是一个$(valid，address)$的二元组，其中$valid$为0/1，$address$为一个地址指针 (此处是为了简化，实际$address$存储的是物理页号，下文会提到) 当$valid$为1时，表示对应的虚拟页存储在物理地址为$address$的主存中 当$valid$为0时，若$address$不为$NULL$，则表示对应的虚拟页在磁盘上的起始地址为$address$，否则表示该页还未与磁盘相关联

同时，我们可以通过对PTE上增加一些额外的许可位来控制一个进程的访问权限，进而避免了破坏其它进程的地址空间，如添加$SUP$位表示是否只能在内核模式下访问，$READ$，$WRITE$位表示能否进行读写

当一条指令违反了这些权限时，就会产生异常控制流，shell将其报告为"段错误"

页命中与缺页

当访问的虚拟页的信息已经存储在物理页中时，对应的PTE的$valid$位为1，$address$位参与构造物理地址，这就称为页命中

当访问的虚拟页不在物理页中时，对应的PTE的$valid$位为0，此时就会产生一个缺页异常，调用内核中的缺页异常处理程序。内核会选择一个牺牲页，若它被修改过则写回磁盘，然后把需要的虚拟页调入某个物理页，并更新相关PTE。此后异常处理程序结束，重新执行触发缺页的指令，若异常处理成功就会产生页命中

页分配

虚拟内存的作用

1. 简化链接：每个目标文件使用的内存格式相同，如数据段都从虚拟地址0x400000开始，这极大简化了链接
2. 简化加载：在一个进程中加载目标文件时，加载器直接为加入的数据段和代码段分配虚拟页，并将其对应PTE设置为未缓存的即可
3. 简化共享：不同进程中的不同虚拟页可以对应相同的物理页，当该物理页是共享库时，就完成了共享，不需要将共享库多次载入到主存中
4. 简化内存分配：当分配空间生成了$k$个连续的虚拟页时，对应的物理页不需要连续，可以分散在物理内存中

地址翻译

传入一个虚拟地址后，MMU采用以下的机制进行地址翻译得到物理地址：

虚拟地址由两部分组成，$p$位的虚拟地址偏移量，和剩下$n-p$位的虚拟页号 虚拟页号表明了这个地址处在第几个虚拟页中，同时也是对应的PTE编号 由于物理页直接对应于一个虚拟页，所以虚拟地址偏移量与物理地址偏移量相同

硬件整体执行的流程如下

TLB加速地址翻译

一次对虚拟地址的访问，需要MMU访问高速缓存得到PTE，构造出物理地址后再次访问高速缓存得到该地址存储的具体值 为了简化得到PTE的过程，进而减少对高速缓存访问造成的开销，MMU内置了一个关于PTE的缓存，翻译后备缓存器(TLB)

类比高速缓存，对于一个有$T=2^t$个组的TLB，组索引来自虚拟页号VPN的低$t$位，页内偏移VPO不参与TLB查找；VPN剩下的高位作为标记位进行校验

同时，各级高速缓存也可能保存PTE的缓存

多级页表

现代计算机实际上采用的是多级页表的结构，即上一级页表中存储的是下一级页表的地址，最后一级页表存储的才是虚拟页的信息。这样构成的是一种树形结构

只有当一个页表的下一级至少有一个页是分配了的时候，该页表才非空，会分配空间，这极大节约了空间。TLB会缓存最终的地址翻译结果，因此TLB命中时无需逐级访问页表；但TLB不命中时，多级页表仍可能带来多次内存访问

Intel Core i7/Linux 内存系统

咕咕咕

内存映射

通过文件对虚拟内存进行初始化的过程称为内存映射 内存映射分为以下两种：

1. 文件映射：使用来自磁盘的文件对虚拟内存进行初始化
2. 匿名映射：映射不依赖普通磁盘文件，内核按需提供初始化为0的页面，因此也被称为“请求二进制零”的页面

共享对象与私有对象

物理页中的一个对象可以同时被多个进程的虚拟地址使用，分为共享对象和私有对象 共享对象指一个进程对该对象的修改会反映到共享的底层对象或物理页上，并且可以被其它映射该对象的进程看到；私有对象指修改会通过写时复制变为进程私有副本，不会反映到其它进程或原始文件中

共享对象示意如下

具体实现上，采用了修改PTE，使得不同的虚拟页面指向同一个物理页面，并且这些对应的PTE都有读写权

私有对象示意如下

具体而言，私有对象采用了一种“写时复制”(copy-on-write，COW)的机制。在最初不同进程虚拟地址的PTE都指向物理地址中的对象，这些进程对应此对象的PTE上都只有读权限，当一个进程尝试进行写的时候，由于没有写的权力，会触发一个故障处理程序，该故障处理程序将私有对象被访问的物理页拷贝一份在为其新分配的物理空间上，并将该页对应的PTE指向此处，设置读写权。然后再重新执行这个写操作，就能正常执行了。写时复制通过推迟复制操作直到对象被修改，极大节约了物理内存。

fork execve 与内存

当执行fork函数时，内核为子进程分配PID，同时将父进程的页表拷贝到子进程中，使它们每个虚拟页指向相同的物理页，然后将PTE权限都设置为只读，采用COW机制即可

当执行execve函数时，先解除原程序在对虚拟空间的映射，使用内存映射将新程序的信息载入虚拟空间，然后将PC跳转到新程序指令起始位置

用户级内存映射mmap

mmap函数原型如下，实现了用户级的内存映射

函数中部分参数的意义如下

对于剩余的参数prot，该参数指定了虚拟内存的权限访问位，可以为以下几种

注意，可以将这个常量采用或运算来给予多个权限

对于参数flags，可以为$MAP_PRIVATE$，$MAP_SHARED$，$MAP_ANON$ （此处应该有爱音唐笑嘿嘿嘿），分别表示共享对象，私有对象，匿名映射。匿名映射可以与前两个进行或运算

要想删除虚拟空间的一部分，可以使用$munmap(start, length)$对start为起点的length字节虚拟空间进行删除

动态内存分配

动态内存分配器维护了一个进程的虚拟空间，该区域被称为堆 堆从.bss区上面向上生长，内核为其维护了一个$brk$指针指向堆顶，堆的大小定义为brk减去堆的起始地址

动态内存分配的用户级函数

malloc 返回一个至少为size字节的内存块的起始地址的void类型指针，由于需要内存对齐，这段内存字节大小可能大于size 当发生错误时(如内存不足)，malloc会返回NULL，并可能设置errno 注意：malloc 不会初始化这段内存的值，要初始化为0可以使用calloc

当incr为0时，可以得到当前的brk指针

注意：free的参数必须为NULL，或为尚未释放过的malloc类函数返回值

动态分配器的基本原则

1. 对于任意一个释放内存操作，此前必须存在对应的分配内存
2. 立即响应，不能延迟操作
3. 不能依赖额外的复杂全局数据结构；分配器维护空闲块所需的数据结构通常存放在堆本身中
4. 进行内存对齐
5. 不对已经分配的内存块进行操作，避免指针失效

动态分配器需要做到效率和效果的平衡 前者用最大吞吐率衡量，即单位时间能完成的分配/释放操作 后者用峰值利用率衡量，具体来说，当前已分配块的有效载荷总和称为有效载荷，峰值利用率定义为运行过程中有效载荷峰值与堆大小的比

隐式空闲链表

下文假设内存按照8字节对齐，称1个字为4字节

块的结构如下

块开头和结尾的头部，脚部是完全相同的，大小都为1个字32位。前29位表示这个块的字节大小(头部与脚部地址的差)，由于内存按8字节对齐，所以大小的后三位一定全为0，所以不需要显式地表示出来，可以用来存储其它的信息，比如这个块是空闲的还是已经被分配的。中间分别为这个块的有效载荷和填充。

通过块头部记录的大小可以跳到下一个块，通过空闲块的脚部可以找到前一个块的大小。这样所有块按内存顺序形成隐式链表；它不同于显式链表，并不在每个块中保存前驱/后继指针

分配内存

介绍以下三种算法：

1. 首次适配：从头开始遍历空闲链表，第一次遇到大小足够的内存块就将其分配到这段内存
2. 下一次适配：从上一次成功适配的位置开始遍历空闲链表，其余步骤同上
3. 最优适配：遍历整个空闲链表，分配到大小足够且最小的那一段内存上

分割空闲块

当直接分配极度不优时，如申请1个字节的空间，但是只有一个114514字节大的空闲块时，就可能会从这个大块中分割出小块用来满足这个申请

合并空闲块

当一个被分配的块被释放时，可能创造连续的空闲块，显然创造的连续空闲块只可能是被释放块与其前后的一共三个块，利用边界标记即可在常数时间内判断并合并相邻空闲块

获取额外的堆内存

当空闲块已经最大程度合并，还是无法满足当前的申请时，分配器调用sbrk函数改变堆顶指针，向内核请求新的堆内存，该内存以一个大的空闲块的形式，插入到空闲链表中

显式空闲链表

显式空闲链表是对隐式空闲链表的一种优化，空闲块由于为被分配，有效载荷部分为空，可以额外存储信息。于是显式存储了当前空闲块的前一个和后一个空闲块的指针，使得每次寻找空闲块时无需遍历已分配块，降低了时间开销

分离存储技术

可以将使用一个大的链表维护堆改为使用多个小的链表进行维护，将这些链表按照块大小范围分为多个类。当进行分配和释放时，只需优先遍历对应大小类的链表，而非整个链表

分离存储的方法包括简单分离存储，分离适配，伙伴系统等

垃圾收集

当某个被分配的块使用完毕后，可以无需显式地释放内存，而使用垃圾收集器，定期地识别并回收无用的内存，Java等语言就是利用该机制释放已经分配的块的

具体而言，当一个内存空间被寄存器，全局变量，用户栈中的变量指向时，这个内存一定需要保持有效。所以我们将后面这些变量看做根节点，已分配块看做是堆节点，当发生a对b的引用时，就连一条a到b的有向边，进而构成了一张有向可达图。所有从根节点出发不可达的堆节点显然就是无用的内存，需要被回收。当malloc找不到空闲块时，就会调用垃圾收集器，从所有根节点出发遍历所有可达的节点并标记，再依次遍历堆，释放所有未被标记的堆节点。然后再次尝试malloc，若还是没有合适的空闲块再尝试向内核获取额外的堆内存

philosophies of C++ design

1. 程序员拥有完全的控制权，并需要对此负责
2. 在代码中直接表达思想和意图
3. 尽可能在编译时强制执行安全性
4. 不浪费空间和时间
5. 将杂乱的特性模块化
6. 向下兼容

stream

std::ostringstream 定义一个写缓冲区，采用 << 从缓存区指针处写入字符串覆盖

std::istringstream 定义一个读缓存区，采用 >> 依据右变量的类型，从缓冲区指针开始读入并进行类型转换。更具体地说，指针会一直读取并向后移动直到遇到空白或制表符，然后指针重新指向空白或制表符的前一个位置。下一次进行缓存区读时，指针会跳过所有空白和制表符，直到下一个字符

事实上，std::istringstream是一种 std::istream，而 std::cin 是一个 std::istream类型的对象，std::cout同理

使用缓冲区而不是立即输出，避免了系统调用读写的昂贵开销，但 std::cerr是不使用缓存区直接输出

缓冲区的状态：Good/Fail/EOF/Bad bit，可通过一个缓冲区的成员函数进行访问 如.good()

当尝试读入的类型于缓存区中识别的类型不一致时，fail位会被设置为1，并且此后对该缓冲区的读入都会被冻结

modern C++ data type

类型别名 eg: using iter = std::vector <int>::iterator

auto 编译器从初值赋值自动推断类型 注意：用 const为 auto变量赋初值的时候不会有常量性

std::tuple类似 std::pair，用来表示多元组，通过 get<i>(x)访问多元组 x的第 i个元素，类似语法通过 set来设置元素的值

统一初始化：按照结构体中变量定义的顺序使用花括号进行初始化

STL

ez

template

C++ 使用 template 实现了类似泛型编程的功能

对于模板函数，可以使用 template <class T> 声明使用了类型为 T的参数

在编译的时候，编译器会对应不同的类型进行实例化，替换生成对应类型的函数；你也可以手动进行实例化 mymax<int>(114,514)加快编译速度

同样的，自定义的函数也可以作为模板函数的参数。注意在C++标准库中，部分模板函数只接受谓词函数，即返回布尔值的函数

lambda 函数：创建的是一个对象，但是表现得像一个轻量级函数，其声明如下

auto fun = [capture-clause](parameters)->return-value{//body};

编译器实际上会把它转化成一个类，由于这个类的名称未知，需要使用 auto

其中的 capture-clause 规定了该lambda 函数能够捕获的外部变量

class

使用构造函数和析构函数，可以定义一个类被创建和回收时的行为

操作符重载分为成员函数和非成员函数两种，前者在类中被定义，后者在类外被定义

部分操作符只能以其中一种形式进行重载，如我们重载std::cout的 <<，使得其能够输出我们自己定义的一个分数类，就只能采用非成员函数进行定义。在成员函数中，可以使用*this得到一个指向当前类的指针

操作符重载的基本原则是和基本类型规则保持一致，如定义分数类的+=时，为了和普通int a 的 (a += 1) += 2;规则相匹配，运算符的返回值应该是一个对当前变量的引用，而非一个拷贝值

采用friend定义友元函数，使得一个位于类外部的函数能够访问类的私有变量

对于一个类，编译器会自动为其生成四种函数

1. 构造函数(default constructor)：在该对象被创建时调用
2. 拷贝构造函数(copy constructor)：在创建一个新的对象，用旧有的对象对其进行初始化赋值时被调用
3. 拷贝赋值函数(copy assignment)：在对于一个已经存在的对象，用旧有的对象对其进行覆盖赋值时被调用
4. 析构函数(destructor)：在一个对象超出其作用域时被调用

编译器自动生成的函数可能与我们预期的行为不一样，如对于一个自己实现的变长数组的类，会采用指针指向一个地址，当进行拷贝的时候，另外的一个对象指针也会指向该地址，而不是我们期望的深拷贝，即创建该地址表示的数组的副本

通过std::dynamic_cast，可以判断一个对象是否是某个指定类的实例

move semantics

将一个对象插入$vector$的末尾，$push_back$方法会先创建该对象的副本，再将该对象的一个副本插入$vector$末尾，这样就需要创建对象的两个副本；而使用$emplace_back$，会在$vector$内直接创建该对象的副本，更为高效

左值与右值：左值出现在等号左侧，右值在右侧。左值有名称和标识，可以使用取地址符找到该值的地址；右值没有名称或标识，是临时值。

左值引用：&

右值引用：&& 可以延长临时值的生命周期，如 auto&& prt = a +b;

类中还有着以下两个特殊成员函数：

1. 移动构造函数(move constructor)：在创建一个新的对象，用右值对其进行初始化赋值时被调用
2. 移动赋值函数(move assignment)：在对于一个已经存在的对象，用右值对其进行覆盖赋值时被调用

以上两个函数均以右值引用作为其参数，对右值引用进行拷贝，由于右值是临时的，保证了该类不会被通过右值的指针修改。在这两个移动函数中，传入的右值引用有地址，是左值，如果直接使用=会调用拷贝函数，造成额外的开销，可以使用std::move(rhs)将其转化为右值，将其视为临时值进行移动。

使用std::move实现高效的swap

template <class T>
void swap(T &a, T &b) {
    T tmp = std::move(a);
    a = std::move(b);
    b = std::move(tmp);
}

时间复杂度取决于类型T的移动构造函数和移动赋值函数的时间复杂度。如std::vector<T>二者都为O(1)，总复杂度也为O(1)

inheritance

继承：将一个类（派生类）基于另一个类（基类）来构建

class Derived : public Base {
    public:
    	//something
    private:
    	//something
};

这被称为public继承，基类的所有成员在派生类中访问权限不变。而protected/private继承会将基类的public和protected访问权限变为protected/private

在基类中，通过在成员函数前加入关键字virtual得到虚函数，使得该函数可以在派生类中被重写，一旦被声明为virtual，在整个继承链中都是虚函数

通过使用=0可以构建纯虚函数，必须在派生类中进行重写。至少包含一个纯虚函数的类称为“抽象类”，无法被实例化

派生类通过关键字override对基类的虚函数进行重写

基类的虚函数通过关键字final，禁止派生类对该函数重写

注意：当派生类定义了与基类成员中名称相同的变量时，基类的变量会被隐藏，即访问该变量时只能得到派生类的值

当派生类超出其生命周期时，会先调用派生类的析构函数，再调用基类的析构函数，注意基类析构函数应该为虚函数，否则对派生类指向的空间进行释放时，只会调用基类的析构函数，进而可能造成内存泄漏

class Animal {
    public:
        std::string name;
        int age;
        Animal(std::string n, int ag) {
            name = n; age = ag;
        }
        virtual ~Animal() = 0;
};

class Dog: public Animal {
    std::string type;
    public:
        Dog(std::string name, int ag, std::string tp) : Animal(name, ag),type(tp){} 
        virtual void daily() = 0;
        virtual void eat() = 0;
        virtual void sleep() = 0;
    	virtual ~Dog(){}
};

class My_Dog: public Dog {
    public:
        My_Dog(std::string name, int ag, std::string tp) : Dog(name, ag, tp) {}
        void eat() override final {
            std::cout << "eat meat" << '\n';
        }
        void sleep() override final {
            std::cout << "sleep 10 hours per day" << '\n';
        }
        void daily() override final {
            eat();
            sleep();
        }
    	~My_Dog() override final {
            
        }
};

模板被称为静态多态性，在编译时确定具体调用哪个函数；而继承被称为动态多态性，在运行时根据对象的实际类型确定调用哪个函数

namespace

ez

RAII & samrt pointers

考虑以下代码

void fun() {
	int *ptr = new int;
	dosomething...
	delete ptr;
	return;
}

new的作用是在堆上动态分配空间，在fun函数结束后，这些空间不会被释放，除非调用了delete。但是函数主体部分可能有提前return，抛出异常等情况导致delete为被执行。这样就会导致堆上的一块空间一直被占用，这被称为内存泄露

RAII(Resource Acquisition Is Initialization)：若要获得资源，应该始终在构造函数中进行；若要释放资源，应该始终在析构函数中进行。 如 std::ifstream就符合RAII思想：采用文件名对其缓冲区进行初始化，在超出作用域调用析构函数是会关闭文件，而无需显式地关闭文件。

基于RAII思想，现代C++提供了智能指针，如std::unique_ptr std::shared_ptr std::unique_ptr会在调用析构函数时自动释放其所指向的堆上空间，需要注意的是，如果对std::unique_ptr执行拷贝操作，可能导致堆上的空间被多次释放而出错，因此std::unique_ptr没有实现赋值拷贝和构造拷贝 而堆上的空间会在指向其的所有std::shared_ptr都调用析构函数后才会释放，注意std::shared_ptr效率上不如std::unique_ptr

A Tour of C++ by Bjarne Stroustrup

太好了是C++之父我们有救辣

const & constexpr (C++11)

const修饰的值不会被修改，这个值可以在运行时被计算

constexpr修饰的是在编译时计算的常量，可以提高运行时性能

函数必须使用constexpr或consteval(C++20)修饰，才能用于初始化一个constexpr常量；

二者区别在于前者修饰的函数也允许运行时计算，后者只能在编译时计算。同时都必须是纯函数，不能修改全局变量

NULL & nullptr(C++11)

NULL的本质是一个被定义为0的宏，当作为参数传入函数中时，会被编译器当做一个整数而非指针

而nullptr有自己的类型std::nullptr_t，可以隐式转换为任意指针类型，或者采用static_cast进行显式转换

enum class

enum(枚举)是一种简单的用户自定义类型，通过使用助记符代替整数，用于表示少量值的集合

C风格的枚举为enum，C++则为enum class，后者有独立作用域，避免了命名污染，以下介绍都以enum class为例

enum class可以指定枚举的类型与值，默认为int和0-index的整数，语法如下

enum class Days : int {
    Monday = 1,		//default = 0
    Tuesday = 2,	// 1
    Wednesday = 3,	// 2
    Thursday = 4,	// 3
    Friday = 5,		// 4
    Saturday = 6,	// 5
    Sunday = 7		// 6
};

类似命名空间，通过::访问成员，如Days today = Days::Friday;

枚举类不支持隐式类型转换，只能进行显式类型转换，如int today = static_cast<int> (Days::Friday);

枚举类成员只默认定义了赋值，初始化和比较，可以为其自定义其他操作符。占用的空间和一个枚举类型的大小相同

union & std::variant(<variant> C++17 )

union(联合)通过将不会被同时使用的成员放在同一个地址，避免了使用两段地址造成空间浪费。可以采用enum class+union来实现

例如当一棵树只有叶子节点需要保存值的时候，可以这么写

enum class Node_type : bool {
    node_ptr,
    val
};

struct Node {
    Node_type t;
    union value {
        Node *p;
        long long val;
    }v;
    void fun() {
        if (t == Node_type::node_ptr) {
            //do something
        }else {
            std::cout << v.val << '\n';
        }
    }
};

可以使用std::variant简化以上代码

struct Node {
    std::variant <Node*, long long> v; 
    void fun() {
        if (std::holds_alternative<Node *>(v)) {
            //do something
        }else {
            std::cout << std::get <long long> (v) << '\n';
        }
    }
};

std::initializer_list (<initializer_list> C++11)

使用花括号，将类型相同的变量组合起来，浅拷贝得到一个只读的临时数组，用于进行类的初始化

initializer_list可以使用迭代器进行访问，为了强调只读性不支持[]访问

throw-try-catch

throw-try-catch提供了应对异常的机制

当控制流执行到某个地方，接下来会发生异常时，可以通过throw退出当前作用域，将控制流转移到该作用域的调用者，同时传递异常，异常可以是任何类型的变量，但为了可维护性一般建议抛出<stdexcept>中的异常类

将可能发生异常的语句放置于try中，这些语句用throw传出的异常可以被catch进行捕获并处理

例如，可以对Vector越界访问抛出<stdexcept>中的std::out_of_range

template <class T>
class Vector {
    public:
        Vector(int S): ptr(new T[S]), siz(S) {}
        T& operator[](int index) {
            if (index < 0 || index > siz - 1) throw std::out_of_range{"Vector::operator[]"};
            return *(ptr + index);
        } 
    private:
        T *ptr;
        int siz;
};

Vector <int> vec(114);

auto main() -> int {
    try {
        std::cout << vec[115] << '\n';
    }
    catch (const std::out_of_range &err) {
        std::cerr << err.what() << '\n';
    }
}

同时，也可以在catch中使用throw重新抛出异常，向上一级调用传播

通过将函数标明为noexcept，会将任何抛出异常的函数行为都变成std::terminate()

assert (<cassert>) & static_assert (C++11)

assert(cond)(断言)会在运行时检查cond的值，若非真，则会立即终止程序

static_assert(cond, s)可以在编译时检查常量表达式cond的值，若非真，则编译错误，并输出s作为编译错误信息

default functions

类的基本函数通过以下形式进行定义，可以使用default表示采用编译器生成的默认函数，delete声明不生成该操作函数

class My_Class {
    public:
        My_Class();//defualt constructor
        My_Class(sometype);//customized constructor
        My_Class(const My_Class &);//copy constructor
        My_Class & operator = (const My_Class &);//copy assignment
        My_Class(My_Class &&);//move constructor
        My_Class & operator = (My_Class &&);//move assignment
        ~My_Class();//destructor
};

定义构造函数的同时，也定义了参数到类的类型转换

考虑以下代码

template <class T>
class Vector {
    public:
        Vector(int S): ptr(new T[S]), siz(S) {}
        T& operator[](int index) {
            if (index < 0 || index > siz - 1) throw std::out_of_range{"Vector::operator[]"};
            return *(ptr + index);
        } 
    private:
        T *ptr;
        int siz;
};

int main() {
    Vector <int> v(10);
    v = 11;
}

这段代码能够编译成功，是因为最后一行调用了接受int类型的构造函数，完成了int到Vector<int>的隐式类型转换

为了避免这种情况，我们只允许显式类型转换，即按以下方式定义构造函数

explicit Vector(int S): ptr(new T[S]), siz(S){}

拷贝时注意是深拷贝还是浅拷贝，被std::move的左值最好不要在重新赋值前使用

relational operators

当关系操作符的两个操作数地位平等时，一般在类的定义外实现，否则在定义内实现

<=> (C++20) 被称为"宇宙飞船符号"，作用是比较两个相同类的操作数，若相等返回0，小于返回负数，大于返回正数(类似strcmp函数)

当<=>被声明为default的时候，会检查每个元素并按字典序进行比较

当未被声明为default的时候，==操作符不会被隐式定义

user-defined literals

内置类型拥有字面量，用来表明常量的类型，如0x0d000721u表明了这是一个unsigned int 对于用户自定义类，我们也可以实现类似的字面量，使用operator""表示正在定义字面量操作符 例如定义虚数后缀i实现如下

constexpr complex <T> operator ""i(const T &imag) {
    return {0, imag};
}

标准库的一些命名空间也提供了一些字面量

using namespace std::literals::string_literals;
using namespace std::literals::string_view_literals;

auto main -> int {
    std::string_view s = "Ciallo"sv;
    std::cout <<　"Ciallo"s << '\n';
}

template argument deduction (C++17)

在初始化的时候，可以让模板类构造函数自行推导模板类型，无需显式声明

如std::pair p = {114.514, 114};

对于容器类，也可以用std::initializer_list达到以上效果，需要注意的是初始化列表所有参数类型必须相同，否则会产生二义性错误

functor

仿函数又被称为函数对象(function object)，是一种特殊的类，通过重载()应用操作符，使得其可以像函数一样被调用

template <typename T>
class Less {
    private:
        T val;
    public:
        Less(const T &x) : val(x) {}
        bool operator ()(const T &x) const {return x < val;}
};
    
auto main() -> int {
    Less <std::string> l {"Ciallo"};
    std::cout << l(static_cast <std::string> ("QWQ")) << '\n';
}

仿函数可以被用作函数的参数

template <typename Iter, typename f>
int Count_If(Iter bg, Iter ed, f pred) {
    int ans = 0;
    for (auto it = bg; it != ed; it++) {
        if (pred(*it)) ans++;
    }   
    return ans;
}

auto main() -> int {
    Less l {998244353};
    std::vector <int> vec;
    std::mt19937 Rand(1919810);
    for (int i = 1; i <= 100; i++) {
        vec.emplace_back(Rand());
    }
    std::cout << Count_If(vec.begin(), vec.end(), l) << '\n';
}

事实上，lambada函数也是编译器自动生成的一个仿函数

finally

为了实现RAII，相较于使用智能指针，还可以使用作用域终结函数，这种方法对C代码有更好的兼容性

template <typename F>
class Finally {
    private:
        F act;
    public:
        Finally(F &x): act(x) {}
        ~Finally() {
            act();
        }
};

template <typename F>
[[nodiscard]] auto finally(F f) {
    return Finally{f};
} 

void fun(int n) {
    auto *p = malloc(sizeof(int) * n);
    auto fin = finally([&]{free(p);});
    //do something
}

其中，[[nodiscard]]修饰函数返回值需要用左值接受，否则编译时会警告

当fun生命周期结束的时候，fin调用析构函数释放p指向的空间，相较在每个可能退出的位置释放堆上的空间更简便

aliases

在所有的STL container的实现中，都有着这样的代码

template <typename T>
class vector {
    public:
    using value_type = T;
    //something
    private:
    //something
}

所以，我们可以在模板函数中通过访问实例化类的value_type成员，得知其参数类型，进而构建该类型的模板类

if constexpr (C++17)

通过if constexpr(cond)，得以实现编译时if，其中要求cond为常量表达式

通过在编译时计算分支跳转，避免了分支预测错误，提高了运行时效率

concepts (<concepts> C++20)

泛型编程中，参数类型需要满足某些需求，模板才能被实例化。满足需求的类就被称为概念

考虑以下模板函数

template <typename Seq, typename Value>
Value Sum(const Seq &s,Value v) {
    for (const auto &x : s) {
        v += x;
    }
    return v;
}

而这个函数需要保证Seq类支持.begin() .end()以及迭代器移动；同时Value类支持+=，以及Seq存放的变量类型与Value类有可加性

类型名称指示符typename也是一个概念，它只限制了该参数是一个类

STL内置了迭代器概念，如std::random_access_iterator，std::forward_iterator等

我们可以使用requires检查一组表达式是否有效 requires子句接在模板参数列表后，右接一个约束表达式用来限制模板参数 requires表达式产生一个布尔量，描述对类型的要求

template <typename Iter>
requires requires(Iter it, int i) {it[i]; it + i;}
void f(Iter it, int i) {
    //do something
}

第一个requires为子句，第二个 这样就限制了iter支持下标操作和加法操作

同时，我们也可以形式化地定义概念

template <typename T>
concept Equality_comparable = requires (const T &a, const T &b) {
    {a == b} -> std::convertible_to <bool>;
    {a != b} -> std::convertible_to <bool>;
};

此处，我们定义的概念需要满足重载了等于和不等于，并且返回值可以被转换为bool类型

所以，上文的Seq类就可以通过定义一个概念来约束

template <class T>
concept Sequence = requires (T seq) {
    typename std::ranges::range_value_t <T>;//参数类型可以被推断
    typename std::ranges::iterator_t <T>;//T提供了迭代器类型
    {seq.begin()} -> std::same_as <std::ranges::iterator_t <T> >;
    {seq.end()} ->  std::same_as <std::ranges::iterator_t <T> >;//有.begin() .end()函数，且返回类型只能是T的迭代器
    requires std::input_iterator <std::ranges::iterator_t<T> >;//迭代器至少是输入迭代器
    requires std::same_as <std::ranges::range_value_t<T>, std::iter_value_t<T> > ;//看不懂喵，ds告诉我是避免代理迭代器
};

标准库中也提供了一些概念，以上代码可以简写为

template <class T>
concept Sequence = std::ranges::input_range <T>;

同时，概念放在auto前，用来约束用auto修饰的变量和参数，当不符合概念时，编译会出错，这避免了对auto的滥用

variadic templates(C++11)

可变参数模板允许我们接受任意数量，任意类型的参数，具体实现上采用递归

template <typename T>
concept Comparable = requires (T a, T b) {
    {a > b} -> std::convertible_to <bool>;
};

template <Comparable T, Comparable... Tail>
requires (std::same_as <T, Tail> && ...)
T Max(T head, Tail... tail) {
    T ret1 = std::move(head);
    if constexpr(sizeof...(tail) > 0) {
        T ret2 = Max(tail...);
        if (ret2 > ret1) return ret2;
    }
    return ret1;
}

使用编译时if而不是运行时if，避免了生成边界情况下参数只有一个的Max函数

但是问题在于可变参数模板由递归实现，开销较大，可以使用数组版本代替

template <Comparable T, Comparable... Tail>
requires (std::same_as<T, Tail> &&...)
T Max(T v, Tail... tail) {
    T values[] = {std::move(v), std::move(tail)...};
    return *std::max_element(std::begin(values), std::end(values));
}

perfect forwarding(C++11)

没看懂，以后来填坑

const & class

通过在类方法后加上const限制，使得该类的成员不能被方法修改(mutable修饰的成员除外)，但成员管理的资源可以被修改

对于const对象，其调用的方法必须有const修饰，用来保证其只读的属性

在一个方法被调用时，编译器会根据对象的const属性选择匹配的版本：const对象调用const修饰的方法，non-const对象调用未使用const修饰的方法(如果存在)

所以为了保证类的const正确性，推荐对所有不修改成员的方法使用const修饰，同时为一些方法提供const和non-const两个版本

std::string & std::string_view (C++17)

std::string 实现上采用了SSO(短字符串优化)技术，短字符串(一般20个字符以下)会被保存在std::string对象内部，长字符串才会在堆上分配空间 因此对于短字符串的操作速度比长字符串快很多

使用std::string_view，我们可以很方便地实现子串提取等功能 std::string_view本质是一个(指针，长度)的二元组，不拥有其指向的对象，只读

std::string append1(const std::string &s1, const std::string &s2) {
    return s1 + s2;
}

std::string append2(std::string_view s1, std::string_view s2) {
    std::string s {s1};
    return s += s2;
}

auto main() -> int {
    std::string s = "Ciallo0d0007211145141919810"s;
    std::cout << append1({&s[0], 20}, s) << '\n';
    std::cout << append2({&s[0], 20}, s) << '\n';
}

append1函数参数为一个子串的时候，需要构建一个临时字符串，该字符串需要分配内存 append2函数则只拷贝了指针和长度，拷贝开销极小 需要注意的是，std::string_view不延长生命周期，指向的对象必须存活

file stream

在算法竞赛中有这样一种文件输入输出方式

int main() {
    std::ios::sync_with_stdio(0);
    std::cin.tie(0);
    std::cout.tie(0);
    freopen("problem.in", "r", stdin);
    freopen("problem.out", "w", stdout);

    int n;
    std::cin >> n;
    //dosomething
}

但事实上，这是一种未定义行为，freopen属于C标准库函数，只修改了C标准流的流指针，而std::ios::sync_with_stdio(0)将C++流与C流独立开来 如果我们先freopen再std::ios::sync_with_stdio(0)，则是先修改C流指针再将C++流和C流独立，这样是正确的 更稳妥的写法是使用std::ifstream和std::ofstream(<fstream>)

auto main() -> int {
    std::ifstream fin("problem.in");
    std::ofstream fout("problem.out");

    int n;
    fin >> n;
    //dosomething
}

parallel algorithms(<execution> C++17)

标准库提供了对于并行执行和向量化执行的支持 std::execution中有以下参数： seq顺序执行 par并行执行 unseq向量化执行 par_unseq并行且向量化执行 例如std::sort可以写成如下形式 std::sort(std::execution::par_unseq, vec.begin(), vec.end()); 注意执行策略指标仅仅是一个提示，使用何种程度的并发取决于编译器

核心模型：AI 时代的关键变化不是“模型会写代码”，而是原来不可 scale 的高级智能活动开始被 scale。操作系统仍然重要，因为 OS 训练的是接口、抽象、状态机、硬件边界和系统正确性。

1. LLM: 大、语言、模型

大语言模型可以拆成三个词：

• 大：足够大的系统会出现稳定的宏观规律和涌现能力。类比 Schrödinger 的问题：单个原子不可预测，但宏观物体可预测；模型参数、数据和计算量足够大后，也会出现训练目标之外的能力。
• 语言：语言是人类长期沉淀的世界模型接口。LLM 不是直接接触物理世界，而是从人类文本中学习一个已经被人类社会对齐过的世界表示。
• 模型：模型不需要精确复制世界，只需要形成一个足够有用的近似。它通过 token 预测吸收语言结构、知识和推理模式。

所以 LLM 的能力不是魔法，而是：

大量数据 + 大模型 + 可扩展训练目标
  -> 学到人类语言中的世界模型
  -> 涌现推理、代码、规划等能力

2. Agent: 从回答问题到操作系统

LLM 本身更像一个强大的策略函数；Agent 则是把它放进一个可行动的闭环：

工作区/记忆 -> 计划 -> 工具调用 -> 观察结果 -> 修正计划 -> 继续执行

Agent 的关键组件：

• 记忆：完整工作区、上下文、Git repository，而不是单轮 prompt。
• 分解：把任务拆成可执行的步骤。早期 prompt 里的 think step by step，在 Agent 中变成持续的规划和检查。
• 工具：搜索、编译、运行测试、编辑文件、调用 sub-agent/skills。工具弥补 LLM 在精确计算、环境感知和真实副作用上的短板。
• 协议：MCP 这类协议把工具调用标准化，使 Agent 能接入不同系统。

OS 类比：

程序 -> syscall/POSIX -> 操作系统资源
Agent -> MCP/tools -> 外部世界资源

这个类比很重要：syscall 让普通程序以受控方式操作文件、进程、地址空间；MCP/tools 让 Agent 以受控方式操作代码库、浏览器、数据库、命令行等环境。接口设计决定了能力边界，也决定了错误会以什么方式传播。

3. Scaling Law: 量变为什么能引起质变

The Bitter Lesson 的观点：不要把太多人工启发式硬编码进系统，而要构造能利用计算规模的通用方法。历史上的 Google、DeepBlue、AlphaGo 都体现了类似路径：当数据、存储、搜索或计算能持续扩大时，能力曲线会发生质变。

LLM 的 Scaling Law 把这种经验变成了实验规律：

loss 与参数量 N、数据量 D、计算量 C 近似呈幂律关系

含义不是“只要堆算力就自动正确”，而是：

• 能力提升具有可预测性，投资更大训练规模有实验依据。
• 训练时 scaling 提升基础能力。
• 推理时 scaling 通过更长思考、多次采样、搜索、工具调用提升单次任务表现。

可以把它理解成两条正交轴：

训练时 scaling: 更大模型 + 更多数据 + 更多 FLOPs
推理时 scaling: 更多中间计算 + 搜索 + 工具 + 验证

Agentic AI 的意义在于把推理时 scaling 工程化：一次回答不够，就拆任务、调用工具、跑测试、回读结果、迭代。

4. Prompt Engineering 本质是 Attention Engineering

Transformer 的核心是 attention。所谓 prompt engineering，本质上是在管理模型注意力：

• 给出正确上下文，避免模型在无关信息上耗费注意力。
• 显式分解问题，降低单次推理跨度。
• 定义检查条件，让模型知道什么算完成。
• 把可验证的部分交给工具，而不是让模型凭语言直觉猜。

没有合适的上下文和接口，LLM 容易输出“看似合理但不可验证”的车轱辘话；有工具和检查闭环后，它才更像一个能工作的工程系统。

5. 软件工程视角: 构建合适的抽象

软件工程的核心仍然是复杂性分解：

软件生态 -> 系统调用 -> OS 实现
OS/软件生态 -> ISA -> 硬件实现
大型软件 -> 函数接口/模块协议 -> 子系统实现

接口带来组合性和复用性，但也引入约束：一旦接口改变，调用方和实现方都可能失配。LLM 可以帮忙维护这些连接，但如果接口文档、测试和协议不清晰，它也会把局部看似合理的修改扩散成全局失控。

因此 AI 编程不是取消软件工程，而是提高了对工程边界的要求：

• 写清楚 API、输入输出、错误语义和不变量。
• 把系统拆成能独立验证的子系统。
• 让 Agent 面对文件系统、测试脚本、协议文档，而不是只面对一段含糊需求。

6. Vibe Coding 的边界

AI 可以快速生成框架代码、脚本、应用逻辑和常见模式，但 OS/系统级代码的风险在于：正确性依赖不可含糊的底层事实。

危险区域包括：

• 寄存器、ABI、调用约定、栈布局。
• 中断、异常、特权级切换。
• 并发原语、内存序、lost wakeup、data race。
• 内存管理、页表、地址空间、对象生命周期。
• 设备寄存器、MMIO、同步和缓存一致性。

这些地方不能只看“代码像不像”。必须问：

状态机是什么？
不变量是什么？
硬件/ABI/内核接口保证了什么？
哪里有 UB、竞争、重排或平台假设？
测试能否覆盖错误路径？

这就是 OS 课在 AI 时代仍然有价值的原因：代码变便宜后，真正稀缺的是系统模型、抽象边界、调试能力和验证意识。

7. 本讲 takeaway

1. LLM 的核心是可 scale 的世界模型近似：大模型从语言中吸收人类知识和推理模式。
2. Agent = LLM + 工作区记忆 + 计划 + 工具 + 反馈闭环；它更像一个能调用 syscall 的程序，而不只是 chatbot。
3. MCP/tools 对 Agent 的意义类似 syscall/POSIX 对普通程序的意义：提供标准化、受控、可组合的外部能力。
4. Scaling Law 说明 AI 能力增长有经验规律；推理时 scaling 让 Agent 能通过迭代和验证提升任务质量。
5. Vibe Coding 适合高层、可快速验证的代码；在 OS、并发、ABI、内存管理等底层场景，必须回到状态机、不变量和硬件事实。

8. 和 OS 主线的连接

• 第 1 讲强调 “Code is cheap, show me the talk”：AI 让代码生成更便宜，但系统设计和解释能力更贵。
• 第 2 讲从应用看 OS：程序通过 syscall 访问 OS；本讲对应 Agent 通过 tools/MCP 访问外部世界。
• 第 3 讲从硬件看 OS：硬件只执行状态迁移；本讲提醒我们 AI 也可能缺乏精确硬件模型，不能用语言流畅性替代系统正确性。

最终结论：AI 是强大的外部执行器，但 OS 能力决定你能不能给它正确的抽象、检查它的输出，并在底层出错时定位真实原因。

1. 本课定位与三条线索

这一讲是虚拟化部分的收官，不是新增零散考点，而是把前面学过的系统调用串成一条完整故事线：

CPU Reset -> Firmware -> Bootloader -> Kernel -> 第一个进程 -> 真实 Linux 用户态 -> 应用生态

核心 message：

操作系统给应用程序提供对象和 API；前面讲过的进程、文件描述符、libc、链接加载，都在解释这套 API 怎么工作。

虚拟化部分的四块拼图：

• 进程与地址空间
• 文件描述符与内核对象
• C 标准库与系统调用封装
• 链接、加载与 execve

本课三条线索：

• 历史线：UNIX -> MINIX -> Linux
• 动手线：initramfs -> 最小 init -> BusyBox -> switch_root -> 可用 Linux
• 生态线：内核 API -> 工具链/运行库 -> 包管理 -> 应用生态

2. UNIX、fork 与 MINIX

最早的 UNIX 甚至没有 fork。shell 运行命令的方式很原始：

1. 关闭原有文件
2. 把 fd 0/1 接回终端
3. 把自己从内存卸掉
4. 加载目标程序执行
5. 程序退出后再把 shell 重新加载回来

也就是说，同一时刻往往只有一个用户态程序在跑。后来的 fork 之所以早期能用很小的代码实现，是因为当时的进程抽象本来就很薄，只涉及少量段边界、寄存器状态和内核 bookkeeping。

MINIX 的意义在于，它把操作系统做成了可完整阅读、修改和教学的系统：

• MINIX 1：UNIX v7 兼容
• MINIX 2：POSIX 兼容
• MINIX 3：更成熟，仍在维护

它也是 Linus 早期写 Linux 的直接土壤。

MINIX 代表的还是微内核路线：

• 内核尽量小
• 文件系统、驱动、内存管理尽量放到用户态服务
• 彼此靠消息传递协作

它的问题不是思想错误，而是当年的 IPC 和调度切换开销太大，所以“过早正确”。

3. Linux 的诞生与时代问题

1991 年 Linus 发出那封 “just a hobby” 邮件时，Linux 还只是一个给 386 机器写的、替代 MINIX 的 UNIX-like 系统。早期 Linux 并不是凭空出现，而是站在已有土壤上长出来的：

• 依赖 MINIX 的环境
• 依赖 GNU 的编译器和工具
• 依赖已有的用户态生态

Tanenbaum-Linus 论战表面上是“微内核 vs 宏内核”，本质上是：

• Tanenbaum 强调结构上的先进与优雅
• Linus 强调当下硬件、性能和可用性

后来的历史说明，技术方向不只看“概念是否先进”，还要看它是否处在合适的硬件和时代上。

课里插入 AI 的意思也类似：今天从 0 到 0.1 做出系统原型，比过去容易得多。重点不是等机会，而是看懂机制、做出最小版本、在可观测现实里迭代。

4. 初始状态与启动链

这节课从“初始状态”重新串起前面的知识。

进程的初始状态由 execve(path, argv, envp) 决定：

• 建新地址空间
• 装入 ELF 与解释器
• 准备初始栈 argc/argv/envp/auxv
• 让 PC 跳到入口

计算机系统的初始状态则是：

• CPU Reset
• Firmware 接管
• Bootloader 加载内核
• 内核最终启动第一个用户态进程

所以问题落到一句话：

第一个进程住在哪里，它怎么把整个 Linux 世界长出来？

后半段的主线就是：

Firmware -> Bootloader -> Kernel -> initramfs:/init -> switch_root/pivot_root -> 真实根 -> /sbin/init -> systemd services

这里要明确区分两个世界：

• 早期启动世界：initramfs
• 发行版世界：真实根文件系统上的用户态

5. initramfs 与第一个进程

initramfs 是启动早期的临时根文件系统，不是平时看到的完整 Linux 世界。

它存在是因为内核刚起来时，常常还不能立刻访问真正的根分区，这时可能还缺：

• 块设备驱动
• 文件系统驱动
• LVM/RAID/加密卷支持
• 找根分区的脚本和配置

所以它的任务很明确：

1. 加载剩余驱动
2. 找到真实根分区
3. 挂载真实根
4. 切换到真实根

最早的第一个用户态进程通常不是 systemd，而是 initramfs 里的 /init。它可以通过内核命令行显式指定：

rdinit=/init

这个 /init 可以是 ELF，也可以是 shell 脚本。也就是说，“第一个进程”不是魔法，而是可控状态。

6. 最小 init 与 PID 1 panic

最小实验的目标，是证明：

Linux 加载的第一个用户态进程，可以由我们自己构造。

做法是写一个只会：

• write
• exit

的最小程序，把它打包进 initramfs，再用 rdinit=/init 让内核把它当作第一个进程运行。

如果这个最小 /init 直接退出，内核会 panic：

Attempted to kill init!

原因不是“它权限高”，而是：

• PID 1 是用户态世界的根
• 它承担进程树和系统服务的生存结构
• 它死了，内核无法把系统视为仍然正常运行

这里对应的不变式是：

内核一旦把控制权交给用户态，用户态根必须持续存在。

7. BusyBox、initrd 与救援 shell

真实的 initramfs 通常不是只放一个二进制，而是放一套最小用户态环境。BusyBox 的作用就是一次性提供大量基础命令，例如：

• sh
• mount
• switch_root
• ls/cp/cat
• 各种恢复和诊断工具

所以 initramfs 虽然小，但已经是一个真正能跑脚本、能挂文件系统、能排错的用户态世界。

把真实机器的 initrd 解开后，会看到它像一个微型 Linux：

• /init 启动脚本
• BusyBox 命令集
• 文件系统和设备驱动模块
• 键盘、字体、firmware 等启动资源

这说明开机早期并不是“只有一个内核”，而是已经有一个缩小版用户态环境。

开机失败时掉进 BusyBox shell，通常不表示“内核死了”，而表示：

• 内核起来了
• initramfs 起来了
• 但从临时根切到真实根这一步失败了

常见原因：

• 根分区找不到
• fstab 写错
• 磁盘或文件系统损坏
• 加密卷没解锁

所以这个 shell 本质上是早期启动阶段的故障恢复入口。

8. switch_root、systemd 与完整 init

这节课最关键的系统调用/工具节点是：

• pivot_root(new_root, put_old)
• switch_root

它们做的不是“再启动一个系统”，而是：

把当前进程看到的根目录，从 initramfs 切换到真实根文件系统。

典型流程：

1. mount 真实根到 /new_root
2. pivot_root 或 switch_root
3. exec /sbin/init

systemd 通常最终是 PID 1，但它不是最早那个进程。真实过程是：

• 早期 PID 1 是 initramfs 里的 /init
• 切到真实根后，它执行 exec /sbin/init
• exec 替换程序映像，但不改变 PID

所以看起来像“systemd 一直都是 PID 1”，其实是 PID 被继承了。

一份能工作的早期 init 脚本，通常会依次做这些事：

• 展开 BusyBox 命令链接
• 挂载 proc、sysfs、dev
• insmod 加载块设备/网卡驱动
• mknod 创建设备节点
• 提供交互 shell 或调试入口
• 挂载真实根
• switch_root

这就是“把 Linux 世界点亮”的最小施工流程。

9. 从最小 Linux 到可用 Linux

从一个空的 initramfs 出发，逐步补齐：

• 命令行工具
• 驱动
• /dev 设备节点
• proc/sysfs
• 真实根
• 第二段 init
• 网络配置
• httpd

最终可以让宿主机浏览器真的访问到虚拟机里的服务。

这一段想证明的是：

一个可用的 Linux 世界，本质上就是一串对象创建和系统调用拼起来的结果。

10. 狭义操作系统、广义操作系统与生态

狭义的 OS 是：

• 对象
• API

也就是：

• fork/execve/waitpid
• open/read/write/close
• mount/mknod/stat/socket
• mmap/munmap/mprotect

广义的 OS 还包括：

• 运行库：libc、libm、libstdc++
• 工具链：gcc、clang、binutils、make
• 包管理：apt、rpm、npm、pip
• 系统管理与应用分发工具

“有没有国产操作系统”这类问题，真正难点不在内核，而在生态：

• 运行库
• 编译工具链
• 包管理
• 应用分发
• 开发者社区
• 长期维护流程

所以：

一张系统调用表不等于一个操作系统；真正让 Linux 无处不在的是围绕它长出来的整座生态。

11. 本课结论

• 前面的进程、文件描述符、libc、链接加载，最终都汇到“OS 提供对象和 API”这一句上。
• Linux 启动链可以拆得非常具体：Reset -> Firmware -> Bootloader -> Kernel -> initramfs -> /init -> switch_root -> 真实根 -> systemd。
• initramfs 是临时根，不是最终世界；最早的 PID 1 是它里面的 /init。
• systemd 是后来的 exec 结果，因此保留了 PID 1 身份。
• BusyBox shell 是早期启动失败时的恢复入口，不等于内核已经崩掉。
• 从最小 init 到联网的 Linux，整个过程都只是系统调用和内核对象的组合，没有魔法。
• 操作系统真正难的往往不是“内核能不能跑”，而是“上面的生态能不能持续支撑应用世界”。

1. 第 8 讲的主线

这一讲讲的不是零散名词，而是一条完整的人机交互链：

人 -> 终端 -> 操作系统 -> shell -> 其他程序

• 终端提供字符交互入口
• 操作系统在这条字符流上附加控制语义
• shell 把系统调用组织成一门命令语言

2. 几个容易混的名词

• tty: 终端接口/设备的总称，历史上来自 teletypewriter
• pty: pseudo terminal，软件实现出来的伪终端机制
• pts: 某个 pty 的 slave 设备实例，例如 /dev/pts/3
• terminal emulator: 终端模拟器，是用户看见的窗口程序
• shell: 运行在终端里的命令解释器，如 sh、bash、zsh

最直白的关系：

你 -> 终端模拟器 -> pty master <-> pty slave(/dev/pts/N) -> shell -> 其他程序

其中：

• 真正执行命令的是 shell 和它 fork/exec 出来的子进程
• terminal emulator 不执行命令，它只负责收输入、显示输出

3. 终端、shell、bash 的区别

• 终端模拟器：窗口和交互界面
• shell：命令解释器这一类程序
• bash：shell 的一种具体实现

所以平时说“打开 terminal”，说的是外层交互环境；里面默认跑着一个 shell。

4. 用户为什么总是从终端进入系统

终端是人机交互的第一个设备。

• 本地登录：内核 -> init -> getty
• 远程登录：sshd -> fork -> openpty

这些程序会先做几件事：

• 分配一个终端
• 让 stdin/stdout/stderr 指向这个终端
• 建立一个 session
• 把这个 session 关联到 controlling tty

login 的作用主要是认证和进入用户环境；严格说，session 往往不是 login 创建的，而是它继承的。

5. 终端到底做了什么

终端本身可以粗略看成“字符输入输出前端”：

• 把按键变成字节流送给操作系统
• 把程序输出的字节流显示出来

但终端不是直接把字符送到某个程序的 stdin。更准确地说：

• 终端把字符送进内核的 tty 子系统
• 内核再决定把这些字符交给哪个前台进程

所以复杂的交互语义主要不在终端模拟器里，而在操作系统的 tty 机制里。

6. Ctrl-C / Ctrl-Z 为什么会“有特殊含义”

终端自己只负责传字符。

• Ctrl-C 常被编码成字节 0x03
• Ctrl-D 常被编码成字节 0x04

这些字节有没有特殊含义，取决于内核保存的这条 tty/pts 的状态。

也就是说：

• 按下 Ctrl-C
• 终端把它送进 tty 子系统
• 操作系统根据当前 tty 配置，把它解释成“给前台进程组发 SIGINT”

所以 Ctrl-C 不是按键自己会杀进程，而是内核在当前终端语义下把这个字符解释成了中断请求。

stty -a 显示的就是当前 tty 的这组状态。

7. 为什么 vim 通常不会被 Ctrl-C 杀掉

因为 vim 运行时会修改终端属性，接管键盘输入。

所以：

• shell 里，Ctrl-C 往往会被 tty 解释成 SIGINT
• vim 里，输入往往先被 vim 自己读走并处理

因此 Ctrl-C 在不同程序里的效果不一样，本质上取决于当前 tty 状态和程序自己的处理方式。

8. session 和 process group 在管什么

这两个分组解决的是不同层次的问题。

session

session 是更大的“登录会话”分组：

• 一整组共享同一个登录上下文的进程
• 通常关联一个 controlling terminal

可以理解成“这一整轮终端交互环境”。

process group

process group 是更小的“作业控制”分组：

• 当前一起工作的那一拨进程
• 例如一条 pipeline 里的多个进程

操作系统收到 Ctrl-C 时，针对的是前台进程组，不是整个 session。

所以：

• session 管“这一大片是谁的终端会话”
• process group 管“当前这一拨进程该一起暂停/继续/收信号”

9. Job Control 是什么

job control 可以看成“终端里的窗口管理”。

• 前台只能有一个 process group
• Ctrl-Z 把前台作业暂停
• fg/bg 在前后台之间切换作业

它的核心问题不是“怎么运行程序”，而是“多个进程组共享一个终端时，谁现在算前台”。

10. shell 的本质

shell 不只是“启动程序的工具”，而是一门极简编程语言。

它做的事是：

• 读入一行命令
• 做文本层面的展开和组合
• 把命令翻译成系统调用序列

典型地会用到：

• open
• dup/dup2
• pipe
• fork
• execve
• waitpid

所以重定向、管道、后台运行，本质上都是文件描述符和进程控制的编排。

一句话：

shell 是 kernel 外面的壳，它把系统调用组织成了用户可直接编程的命令语言。

第 21 讲不是引入一个新 API，而是把前面所有操作系统概念串成一条端到端路径：

用户发出请求
-> 网络与数据中心接住请求
-> 后端把请求排队、鉴权、计费、调度
-> GPU 集群执行 next-token prediction
-> 生成的 token 以 event-stream 形式流式返回

这条路径的核心不变量是：

控制流上，大量并发请求不能被重线程和阻塞等待拖垮；
数据流上，必须把计算搬到数据/缓存/显存附近；
硬件上，必须把工作重排成规则、同构、局部的并行形式。

所以本讲其实是在回答一个大问题：你按下回车后，为什么一个看似普通的 HTTP 请求会穿过整个现代计算机系统栈。

1. 从用户视角看请求

用户看到的只是：

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
  -d '{"model":"deepseek-v4-flash","messages":[...],"stream":true}'

但这一行命令已经触发了很多系统事件：

• shell 创建进程，设置 stdin/stdout/stderr。
• libc / runtime 发起 socket、connect、send、recv 等系统调用。
• DNS 把域名解析成 IP，DNS 本身也可能参与负载均衡。
• TCP/TLS 建立连接，HTTP 请求被发往远端。
• 服务端以 text/event-stream 返回一段段 token。

这一层的关键不是“会用 curl”，而是：

API endpoint 不是一台机器；
它是 DNS、路由、负载均衡、API 网关、业务服务和推理集群共同暴露出来的入口。

域名解析、traceroute、HTTP header 只是我们能从用户侧观察这套系统的几个窗口。

2. 为什么数据中心是核心

数据中心可以粗略看成：

计算资源 + 存储资源 + 网络资源 + 调度系统 + 运维系统

互联网时代，它主要支撑 Web、移动应用、搜索、支付、社交、内容分发；AI 时代，它又变成模型训练和推理的基础设施。

这也是课程里“操作系统不是孤立知识点”的具体体现：

• fd、socket、pipe、mmap 支撑服务间通信和数据搬运。
• 线程、锁、条件变量、信号量支撑后端队列和 worker pool。
• epoll、coroutine、async/await 支撑大量连接的等待型并发。
• 并行算法、分片、缓存和近似计数支撑规模化吞吐。
• SIMD/SIMT/GPU 支撑最终的密集矩阵计算。

一句话：

数据中心是 OS 知识的工业级展开。
​```---
## 3. C10K 到 AI 推理瓶颈

C10K 问题问的是：一台服务器如何同时处理一万个连接。

朴素写法是：

​```c
while (true) {
    Request *rq = get_request();
    pthread_create(&tid, NULL, handle_request, rq);
}

这个模型的问题不在正确性，而在成本模型：

• 每个 OS 线程有栈、TCB、TLS、内核调度实体等资源。
• 阻塞 I/O 会让线程睡进内核。
• 大量线程会带来上下文切换、cache 扰动和调度开销。
• 连接数上来后，线程数不能线性跟着涨。

于是系统演化出：

C10K: epoll / Nginx / event-driven server
C10M: 用户态网络栈 / 零拷贝 / DPDK / 更强的 runtime
C10B: CDN / 边缘计算 / service mesh / 分布式调度

但 AI 推理时代的瓶颈又变了。传统 Web 请求可能主要卡在网络、数据库、缓存和业务逻辑；LLM 请求背后还挂着一次昂贵的 GPU 推理。

所以新的瓶颈是：

并发连接数不再是唯一问题；
每个请求消耗多少 GPU 算力、显存、KV cache 和调度资源，才是核心问题。
​```---
## 4. 一个请求穿过后端

一个 LLM API 请求进入数据中心后，大致会经历：

​```text
DNS / route
-> L4 load balancer
-> L7 reverse proxy
-> API gateway
-> auth / billing / audit / rate limit
-> application server
-> inference queue
-> GPU scheduler
-> CUDA kernels
-> SSE / WebSocket stream

每一层都有自己的 correctness condition。

鉴权要求：

API key disabled 后不能继续无限使用。

计费要求：

实际消耗的 token 必须最终进入账单和日志。

限流要求：

不能因为多节点并发访问同一个 key 就绕过 quota。

推理队列要求：

请求不能丢，取消和超时不能破坏队列不变量。

这些问题很快会撞上分布式系统的墙：延迟、故障、重试、乱序、部分失败、CAP 取舍。单机上一个 mutex 可以保护的东西，到了分布式环境里可能变成跨节点共识、幂等接口、日志重放和最终一致性。

5. UNIX 模型为什么不够

UNIX 很擅长：

open / read / write / pipe
把数据带到本机进程里处理

这对单机系统非常优雅。但大规模分布式系统更常见的方向是：

把计算带到数据附近。

原因很直接：数据太大、机器太多、网络太慢且不可靠。

于是系统接口从“字节流”扩展到更高层：

• GFS / HDFS：把大文件切块复制到多台机器。
• BigTable / DynamoDB：用 key-value / table 抽象支撑在线查询。
• MapReduce / Spark：限制计算形式，使其能被自动分发和容错。
• Serverless / FaaS：用函数描述计算图，让平台负责调度、重试和伸缩。

这里和第 19 讲的 Promise / async 模型有相似之处：

程序员描述依赖关系；
运行时/平台负责在事件完成后推进后续计算。
​```---
## 6. 从 Token 到 Tensor

LLM 推理的核心可以压成：

​```text
p(token_{t+1} | token_1 ... token_t) = f_theta(token_1 ... token_t)

也就是从一个学到的巨大函数里采样下一个 token。

这里的 theta 是参数，f_theta 是 Transformer 计算图。所谓 tensor，本质上就是多维数组：

scalar: []
vector: [C]
matrix: [M, N]
image batch: [B, H, W, C]
attention: [B, Head, T, T]
KV cache: [Layer, B, Head, T, Dim]

讲义强调 llm.c / gpt.c 的意义就在这里：大模型原理上并不神秘，很多核心路径就是数组、下标、循环、矩阵乘、softmax 和采样。

神秘感主要来自规模：

参数量巨大；
张量巨大；
显存压力巨大；
带宽压力巨大；
调度系统巨大。
​```---
## 7. Attention 的系统视角

Attention 可以从 Q/K/V 理解：

​```text
Q: 当前查询，我要找什么
K: 历史内容的索引，它们能匹配什么
V: 历史内容的值，匹配后实际取回什么

推理时，每一层都在把当前 token 的表示和已有上下文交互，得到新的表示。实现上，它会落到一系列张量计算：

linear projection
QK^T
softmax
attention weights * V
MLP
layernorm
sampling

从操作系统/体系结构视角看，关键不是公式本身，而是公式的执行形态：

大量同构算子；
规则但巨大的张量访问；
高带宽需求；
高度依赖 batching、layout、tiling 和 cache。

这就是第 20 讲 SIMD/SIMT 的直接应用场景。

8. CUDA kernel 在做什么

CUDA 的 <<<grid, block>>> 可以理解为：

CPU 把 kernel 参数和执行形状提交给 GPU；
GPU 创建大量逻辑线程；
线程按 block / warp 组织执行；
CPU 通常立即返回，GPU 异步推进计算。

例如矩阵乘里的每个线程或线程块负责输出矩阵的一小块。它和第 18 讲计算图的关系很直接：

节点 = 一个 tile 的本地计算
边 = 全局内存读取、shared memory 同步、kernel 边界

GPU 适合 LLM，不是因为“GPU 比 CPU 神奇”，而是因为 workload 长这样：

• 同一操作重复在大量元素上。
• 分支相对少，控制流比较统一。
• 数据可以被整理成矩阵和张量。
• tile 复用可以提高算术强度。
• Tensor Core 可以高吞吐执行混合精度矩阵 FMA。

真正难点也在这里：

不是写出一个能算的 kernel；
而是让访存、布局、同步、并行粒度和硬件执行单元匹配。
​```---
## 9. Prefill、Decode 与 KV Cache

生成一个回复不是一次性算完，而是反复生成 token。通常分成两个阶段：

​```text
Prefill:
  处理完整 prompt，算出每层的 K/V，写入 KV cache。

Decode:
  每次生成一个新 token；
  读取已有 KV cache；
  用当前 Q 和历史 K/V 做 attention；
  采样出 token；
  把新 token 的 K/V 追加进 cache。

如果没有 KV cache，每生成一个 token 都要重新计算所有历史 token 的 K/V，代价会非常夸张。KV cache 的作用是把历史上下文变成显存里的可复用状态。

但 KV cache 也带来新的系统问题：

• 它占用大量显存。
• 多用户共享时需要分配、回收、驱逐。
• 长上下文会让 cache 线性增长。
• batching 时不同请求长度不同，会造成碎片和调度难题。
• 请求取消、超时、完成时必须正确释放 cache。

这就是为什么现代推理引擎会做 PagedAttention、prefix cache、continuous batching、KV cache paging 等优化。它们本质上都在回答：

怎样像管理虚拟内存和 slab allocator 一样管理显存里的上下文状态？
​```---
## 10. 最后返回的其实是一个整数

GPU 算完后，模型输出 logits：

​```text
logits: [vocab_size]

然后服务端做：

softmax / sampling
-> token id
-> tokenizer decode
-> UTF-8 bytes
-> JSON chunk
-> SSE event-stream
-> reverse proxy / CDN
-> client display

所以“模型吐出一个字”在系统里其实是：

一个整数经过 tokenizer 反查后，被包装成网络字节流返回。

流式输出的体验来自循环执行：

decode one token
send one chunk
decode next token
send next chunk
...

这也解释了为什么首 token 延迟和后续 token 吞吐是两个不同指标：

• 首 token 延迟包含排队、调度、prefill、网络路径等成本。
• 后续 token 吞吐主要受 decode、KV cache 访问、batching 和 GPU 利用率影响。

11. 和前面课程的连接

这讲可以把前 20 讲压成一张系统图：

进程 / syscall / fd:
  curl、socket、HTTP、日志、pipe、event-stream。

mmap / virtual memory:
  大文件、模型权重映射、显存管理、cache paging。

线程 / 锁 / 条件变量 / 信号量:
  请求队列、worker pool、GPU 调度器、限流器。

并发 bug:
  取消、超时、重复计费、UAF、ABA、死锁、日志丢失。

并行算法:
  batching、work stealing、分片队列、调度图。

协程 / async:
  大量连接、网络等待、流式返回、事件循环。

SIMD / SIMT:
  matmul、attention、tensor core、kernel launch。

分布式系统:
  鉴权、计费、审计、CAP、幂等、重试、容错。

这就是讲义的核心：操作系统课不是 API 清单，而是一套还原系统的能力。

12. 面向 AI Infra 的检查清单

分析一个 LLM serving 系统时，可以按这条链问：

1. 请求在哪里等待？等待的是网络、队列、GPU，还是外部服务？
2. 哪些路径是一请求一线程，哪些路径是 event loop / coroutine？
3. 请求队列的 correctness condition 是什么？取消和超时怎么处理？
4. batching 策略是在优化吞吐，还是牺牲尾延迟？
5. KV cache 如何分配、分页、驱逐和回收？
6. kernel 是 compute-bound、memory-bound，还是 launch/sync-bound？
7. tensor layout 是否让访存 coalesced，tile 是否复用到 shared memory？
8. 统计、计费、日志是否允许最终一致？哪些地方必须严格一致？
9. 如果某个节点 crash，哪些操作会重试？是否幂等？
10. P99/P999 latency 的瓶颈是不是被平均吞吐掩盖了？

真正的系统优化不是“把每层都换成最快技术”，而是先定位瓶颈：

连接多 -> 用 event-driven / coroutine；
队列热 -> 分片 / batching / backpressure；
显存紧 -> KV cache paging / eviction；
算力满 -> tensor layout / fusion / tensor core；
尾延迟差 -> 调度、隔离、限流和负载均衡。
​```---
## 本节知识点总结

​```text
1. 第 21 讲的主线是把一次 LLM 请求还原成完整系统路径，而不是介绍孤立新概念。
2. API endpoint 背后是 DNS、路由、负载均衡、网关、业务服务和推理集群共同组成的入口。
3. C10K 说明一连接一 OS 线程不可扩展；epoll、事件驱动和协程把等待成本从线程成本中解耦。
4. AI 推理时代的新瓶颈是每个请求背后的 GPU 算力、显存和 KV cache，而不只是连接数。
5. 数据中心是 OS 知识的工业化展开：fd、线程、锁、队列、缓存、调度和网络都在其中落地。
6. 分布式系统不能只沿用 UNIX 的字节流模型，很多场景必须把计算带到数据附近。
7. LLM 推理本质上是从学到的函数中采样下一个 token，核心实现落在张量、循环、矩阵乘和 softmax 上。
8. Attention 的 Q/K/V 公式最终会落到规则密集张量计算，因此天然适合 GPU/SIMT。
9. CUDA kernel launch 是 CPU 向 GPU 提交大量逻辑线程的异步执行请求，性能关键在布局、访存、同步和粒度。
10. Prefill 负责构建 KV cache，Decode 负责逐 token 读取和追加 KV cache。
11. KV cache 是 LLM serving 的核心系统状态，问题形态很像虚拟内存、cache 和 allocator。
12. 模型最终返回的是 token id；tokenizer decode 后才变成用户看到的 UTF-8 文本。
13. 首 token 延迟和后续 token 吞吐是不同指标，分别受排队/prefill 和 decode/cache/GPU 利用率影响。
14. 本讲给出的能力不是背技术名词，而是用 first principles 还原未知系统的瓶颈、边界和不变量。

M1: 迷宫游戏 (labyrinth)

简要题意：补全一个迷宫游戏的后端，这个后端由前端使用命令行的形式调用

Lab 1: getopt_long 与这次调试踩坑总结

1. getopt_long 是做什么的

getopt_long 用来解析命令行参数，把

./labyrinth --map test.map --player 1 --move right

这种 argv 序列解析成“选项 + 选项参数”的结构，避免手写一堆 strcmp(argv[i], "...")。

常见调用骨架：

static struct option long_options[] = {
    {"map", required_argument, 0, 'm'},
    {"player", required_argument, 0, 'p'},
    {"move", required_argument, 0, 'M'},
    {"version", no_argument, 0, 'v'},
    {0, 0, 0, 0}
};

int opt;
while ((opt = getopt_long(argc, argv, "", long_options, NULL)) != -1) {
    switch (opt) {
        case 'm': map = optarg; break;
        case 'p': player = optarg; break;
        case 'M': move = optarg; break;
        case 'v': version = true; break;
        case '?': return 1;
    }
}

2. getopt_long 每个参数的意义

函数原型：

int getopt_long(int argc, char * const argv[],
                const char *optstring,
                const struct option *longopts,
                int *longindex);

• argc 命令行参数个数。
• argv 命令行参数数组。
• optstring 短选项规则表，例如 "m:p:v" 表示 -m 和 -p 需要参数，-v 不需要参数。 如果只想用长选项，可以传 ""。
• longopts 长选项描述表，也就是 struct option[]。
• longindex 如果不为 NULL，会写入当前匹配到的是 longopts 的第几项。大多数时候可以传 NULL。

3. struct option 的四个字段

{"map", required_argument, 0, 'm'}

• 第 1 项 name 长选项名字，对应 --map。
• 第 2 项 has_arg 参数模式：
  • no_argument
  • required_argument
  • optional_argument
• 第 3 项 flag 常用时直接写 0 或 NULL。
• 第 4 项 val 匹配成功时 getopt_long 返回的值，这里返回 'm'。

最后必须有一个终止项：

{0, 0, 0, 0}

否则解析器不知道选项表在哪里结束，属于未定义行为。

4. 常用全局变量

• optarg 当前选项对应的参数字符串，例如 --map test.map 时，处理 case 'm' 时 optarg == "test.map"。
• optind 下一个待处理参数在 argv 中的下标。解析结束后，如果 optind != argc，通常说明还有未消费的多余参数。
• optopt 出错时记录相关选项。
• opterr 是否让库自动打印错误信息。很多题目里会设成 0，自己控制报错路径。

5. required_argument 怎么判断有没有参数

不要靠 optarg == NULL 来手搓判断，应该看 getopt_long 的返回值。

• 正常匹配到 --map file，会返回你设置的 'm'，并且 optarg 指向 "file"。
• 如果缺少必须参数，通常会返回 '?'。
• 如果 optstring 以 : 开头，例如 ":"，那么“缺少参数”会返回 ':'，可以和“非法选项”区分开。

典型写法：

while ((opt = getopt_long(argc, argv, ":", long_options, NULL)) != -1) {
    switch (opt) {
        case 'm':
            map = optarg;
            break;
        case ':':
            return 1;  // 缺参数
        case '?':
            return 1;  // 非法选项
    }
}

6. getopt_long 的使用顺序

一条比较稳的主线是：

1. 定义 long_options
2. 在 while (getopt_long(...) != -1) 里做语法解析
3. 解析结束后检查语义约束
4. 再进入业务逻辑

例如：

1. 先解析出 map/player/move/version
2. 再检查：
   • 是否缺 --map
   • 是否缺 --player
   • player 是否是合法数字字符
   • move 是否是 up/down/left/right
3. 最后再 loadMap、movePlayer、saveMap

这比“边解析边做大量业务操作”更稳，因为语法层和语义层分开了。

7. 这次自己踩到的坑

7.1 空指针先被用了

原来在 main 里先写了：

strlen(player)

但如果命令行没有 --player，此时 player == NULL，会直接段错误。

经验：

• 先判空，再使用。
• 先检查参数是否存在，再做 strlen、索引、转换。

7.2 误以为 malloc 出来就是“可用对象”

原来写了：

Labyrinth *mp = malloc(sizeof(Labyrinth));

但没有初始化 rows/cols/map，随后 loadMap 里直接使用 labyrinth->rows，会把垃圾值当合法下标。

经验：

• malloc 只保证“给你一块内存”，不保证里面是 0。
• 要么 calloc，要么显式 memset，要么直接用 Labyrinth mp = {0};。

7.3 越界判断写成了开区间

原来用了：

0 < row && row < labyrinth->rows
0 < col && col < labyrinth->cols

这会错误排除第 0 行、第 0 列，导致边界上的合法位置全被判错。

经验：

• 数组下标合法区间是 [0, n)，不是 (0, n)。

7.4 isEmptySpace 没做边界检查

原来直接访问：

labyrinth->map[row][col]

如果传入 (-1, 0) 或 (rows, 0)，就是越界读，单测里正好卡了这个。

经验：

• 所有“带坐标访问数组”的函数，先做边界检查，再读数组。

7.5 switch 漏写 break

case 'M' 后漏掉了 break，导致合法的 --move 也会掉进 case '?' 直接报错。

经验：

• switch 里每个分支都要显式确认是“故意 fallthrough”还是“必须 break”。

7.6 把“只看首字母”当成“解析方向”

原来只看 direction[0]，所以 "diagonal" 会被当成 "down"。

经验：

• 这种有限离散集合，应该做精确字符串匹配。
• up/down/left/right 是协议，不是“首字母提示”。

7.7 saveMap 名字对了，但行为错了

原来 saveMap 里：

• 用 "r" 打开文件
• 用 putchar 往标准输出写

所以它根本没有保存文件。

经验：

• 文件写回要检查三件事：
  • 打开模式是不是 "w" 或可写模式
  • 写的是不是目标 FILE *
  • 写完是否真的关闭/落盘

7.8 混淆了“打印地图”和“报错退出”

原来没有 --move 时会打印地图，但返回 1。

经验：

• “查询模式”和“错误模式”要分清。
• 能正常打印地图，说明程序成功完成了请求，应该返回 0。

7.9 忘了测试框架也会影响命令行解析状态

这次本地 testkit 会在同一进程里多次调用 main，而 getopt_long 的状态不是自动清空的。

经验：

• 如果 main 可能被测试框架重复调用，要注意 getopt 相关全局状态。
• 调试“手工运行正常，测试全挂”时，要怀疑框架调用模型，而不只是怀疑业务逻辑。

8. 这次调试后的简化结论

• getopt_long 负责“把命令行拆成结构化选项”。
• 判空、合法性检查、业务语义检查，要放在解析之后统一做。
• 任何可能为空、未初始化、越界的对象，都不能先用后查。
• 文件 IO 的正确性要分别检查“打开、读写对象、输出目标、关闭”。
• 段错误大多不是“算法错”，而是对象生命周期、边界、空指针、未初始化状态错。

M2: 打印进程树 (pstree)

简化题意：实现一个类似于pstree的进程树打印工具

Lab 2: pstree 与 /proc 接口笔记

1. /proc 接口

• /proc 不是普通磁盘目录，而是 procfs 的挂载点。
• 它对用户态表现成“可以 open/read/... 的文件和目录”，但内容往往是内核在读取时按当前状态动态生成的。
• 因此 /proc/<pid>/... 看到的是“某个进程当前状态的投影”，不是一份持久化文件。

遍历 /proc 下名字为纯数字的目录，可以得到当前时刻“可见的所有进程 pid 候选集合”。

注意这不是原子快照，可能在看到了尝试读取时，文件不存在。

/proc/<pid>/comm 暴露进程名，读取结果是一行字符串。

/proc/<pid>/stat 中，第四个字段给出了父进程信息。

2.做法

对于每个进程都向父进程连接一条边，然后从根开始dfs输出即可。

注意根的id是0,systemd只是第一个用户态进程，事实上很多内核线程挂在 2 下面。

3. 这次实现里踩过的坑

• 把 const int MAXN 当成文件作用域数组大小，实际上在 C 里不算这种用途下的编译期常量
• 只从 PID 1 开始 DFS，导致漏掉 PID 2 及其后代
• 忽略 /proc 的动态变化，读失败后仍继续使用未初始化数据

简化题意：运行 strace 跟踪指定程序，流式读取每次系统调用的耗时，并每隔约 100 ms 输出累计耗时前5高的系统调用。

Lab 3: sperf 与进程间通信接口笔记

1. 整体进程模型

程序中实际存在三层角色：

sperf 父进程
  └─ strace 子进程
       └─ 被跟踪的目标程序

• 父进程负责读取、解析、累计和定时输出。
• fork 出来的子进程通过 execve 变成 strace。
• strace 再启动目标程序，并把跟踪结果写到自己的标准错误。

父进程必须和 strace 并发工作，不能先 waitpid，等它退出后再读取 pipe。否则 pipe 写满后，strace 等待读者，父进程又等待 strace 退出，会形成死锁。

2. strace

常用命令：

strace -T command arguments...

-T 会在每次系统调用末尾输出该次调用的耗时：

read(3, "abc", 3) = 3 <0.000012>

• read 是系统调用名。
• <0.000012> 是这一次系统调用经过的时间。
• strace 默认把跟踪信息写到 stderr，避免和目标程序的正常 stdout 混在一起。
• -c 可以在程序结束后生成汇总表，但不适合本实验要求的流式、周期性输出。

strace 还可能产生信号、退出信息等非系统调用行，因此 parser 不能假设每一行都有 name(...) <time> 的格式。

3. pipe

接口：

#include <unistd.h>

int pipe(int pipefd[2]);

成功后：

• pipefd[0] 是读端。
• pipefd[1] 是写端。
• pipe 是内核维护的单向字节流缓冲区，不保留“行”或“消息”的边界。

对读端调用 read 时：

• 缓冲区有数据：返回实际读到的字节数。
• 缓冲区为空，但仍有写端：阻塞等待。
• 缓冲区为空，并且所有写端引用都已关闭：返回 0，即 EOF。
• 出错：返回 -1，具体原因在 errno 中。

pipe 可读不要求缓冲区已满，只要有任意数据，poll 就可以报告 POLLIN。缓冲区满影响的是写端：此时继续 write 可能阻塞。

4. fork 与 fd 继承

接口：

pid_t fork(void);

返回值：

• 0：当前位于子进程。
• > 0：当前位于父进程，返回值是子进程 PID。
• -1：创建失败。

fork 后父子进程拥有各自的 fd table，但复制得到的 fd 表项仍指向相同的内核文件对象。因此，父子双方都可能持有同一个 pipe 端点的引用。

必须及时关闭不用的端：

• 父进程只读，所以关闭 pipefd[1]。
• 子进程只写，所以关闭 pipefd[0]。

这不只是资源清理。父进程如果忘记关闭自己的写端，内核会认为 pipe 未来仍可能收到数据，读端就无法得到 EOF。

5. dup2 与重定向

接口：

int dup2(int oldfd, int newfd);

它让 newfd 指向 oldfd 指向的同一个内核对象。若 newfd 原本已打开，内核会先关闭它。

本实验中：

dup2(pipefd[1], STDERR_FILENO);

执行后，STDERR_FILENO（fd 2）指向 pipe 写端。此时原来的 pipefd[1] 只是一个多余别名，应当关闭：

close(pipefd[1]);

不能关闭 STDERR_FILENO，因为后续运行的 strace 正是通过 fd 2 向 pipe 写跟踪信息。

6. execve 与参数数组

接口：

int execve(const char *pathname, char *const argv[],
           char *const envp[]);

execve 用新程序映像替换当前进程。成功时不会返回；失败时返回 -1。

它会替换代码、数据、堆栈等用户态内容，但默认保留 fd table，所以在 execve 前完成的 stderr 重定向仍然有效。设置了 FD_CLOEXEC 的 fd 是例外，会在成功执行时关闭。

执行：

strace -T ls -l

对应的参数数组应满足：

argv[0] = "strace"
argv[1] = "-T"
argv[2] = "ls"
argv[3] = "-l"
argv[4] = NULL

关键约束：

• argv[0] 是被执行程序约定的程序名。
• 最后必须有一个空指针，而不是字符 '\0'。
• 字符串字面量本身已经带结尾 NUL，不需要写成 "strace\0"。
• execve 不会自动搜索 PATH；需要搜索时应自行解析 PATH，或使用提供 PATH 搜索语义的其他接口。

7. poll

接口：

#include <poll.h>

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

struct pollfd：

struct pollfd {
    int fd;
    short events;
    short revents;
};

• events 表示希望监听的事件。
• revents 由内核填写，表示实际发生的事件。
• timeout 单位是毫秒；0 表示立即返回，-1 表示无限等待。

返回值：

• > 0：至少一个 fd 发生事件。
• 0：超时。
• -1：出错，例如被信号中断。

本实验主要关心：

• POLLIN：当前存在普通数据可读。
• POLLHUP：pipe 的所有写端均已关闭，不会再产生新数据。
• POLLERR：fd 出现错误。
• POLLNVAL：fd 无效。

父进程只需主动订阅 POLLIN：

pfd.events = POLLIN;

POLLHUP、POLLERR 和 POLLNVAL 即使没有写入 events，也会由内核报告在 revents 中。组合多个事件或检查返回事件时应使用按位或和按位与，不能使用逻辑运算代替。

POLLIN 和 POLLHUP 可以同时出现，表示写端已经关闭，但 pipe 中仍有残留数据。不能看到 POLLHUP 就直接退出，最终 EOF 应以 read(...) == 0 为准。

8. 流式分行

一次 read 与一行 strace 输出没有对应关系。一次读取可能得到：

• 半行；
• 恰好一行；
• 多行；
• 多行加最后半行。

因此需要维护用户态残留缓冲区：

1. 把本次读取的数据追加到残留数据后面。
2. 按 '\n' 提取所有完整行并解析。
3. 把最后不完整的一段移动到缓冲区开头。
4. 等待下一次 read 继续拼接。

这体现了 pipe 的核心语义：它只提供有序字节流，不提供消息边界。

9. 每秒约输出 10 次

100 ms 表示刷新周期，不是统计窗口。每次输出应展示程序开始以来的前缀累计统计：

第 1 次：[0, 100 ms]
第 2 次：[0, 200 ms]
第 3 次：[0, 300 ms]

打印时机不能只依赖 poll 超时。如果 pipe 持续可读，poll 会不断提前返回，可能永远没有 r == 0。

更稳定的模型是维护一个绝对截止时间：

1. 使用单调时钟记录 next_print = now + 100 ms。
2. 每轮把 next_print - now 换算为 poll timeout。
3. 处理完本轮 I/O 后重新读取时间。
4. 若 now >= next_print，输出当前统计并推进截止时间。

计量时间间隔适合使用：

#include <time.h>

clock_gettime(CLOCK_MONOTONIC, &ts);

CLOCK_MONOTONIC 不受系统墙钟时间被人工调整的影响。

10. waitpid

接口：

pid_t waitpid(pid_t pid, int *status, int options);

父进程在读完 pipe、确认 EOF 后调用 waitpid，回收 strace 子进程并取得退出状态，避免产生僵尸进程。

正确顺序是：

持续 poll/read/parse
        ↓
read 返回 0，确认 EOF
        ↓
waitpid 回收子进程

不能在读取 pipe 前阻塞等待子进程结束。

11. 输出 80 个 NUL

printf("\0") 输出不了 NUL，因为 "\0" 对 printf 来说只是长度为 0 的空字符串。

可以逐字节输出：

for (int i = 0; i < 80; i++) {
    fputc('\0', stdout);
}
fflush(stdout);

也可以构造全零数组后使用 fwrite。fflush(stdout) 用于确保 stdio 缓冲区中的结果及时提交。

12. 这次实现中踩过的坑

• 父进程先 waitpid、不读取 pipe，导致 pipe 写满后父子进程互相等待。
• dup2 后忘记关闭多余 fd 别名，干扰 pipe 写端引用计数和 EOF 判定。
• 误以为 pipe 缓冲区满才算可读；实际上存在任意数据即可报告 POLLIN。
• 用按位与组合希望监听的事件，导致 events 变成 0；实际只需订阅 POLLIN，并从 revents 检查 POLLHUP。
• 看到 POLLHUP 就退出，忽略了 pipe 中可能仍有残留数据。
• 认为一次 read 可以读完整行，没有考虑短读、多行和半行拼接。
• execve 的参数数组忘记以 NULL 结尾，或把结尾下标写到分配范围之外。
• 为参数字符串 malloc 后立刻覆盖指针，造成无意义的内存泄漏。
• strace 的非系统调用输出也进入 parser，导致未初始化字符串或错误耗时被加入统计。
• 只在 poll 超时时打印；持续产生 syscall 时，poll 总因 POLLIN 返回而无法稳定刷新。
• 混用微秒和毫秒，导致 timeout 变成约 5 ms 或出现负值。
• 使用 printf("\0")，实际上没有输出题目要求的 80 个 NUL。
• 在 shell 外层写 > /dev/null，连 sperf 自己的标准输出也一起重定向掉了。

13. 总结

• fork 创建并发执行环境，execve 替换子进程程序映像。
• pipe 提供内核字节流，dup2 把 strace 的 stderr 接入 pipe。
• fd 是否仍然打开由引用决定；pipe EOF 的条件是缓冲区为空且所有写端都关闭。
• poll 负责等待“I/O 就绪或时间到达”，read 才真正消费数据。
• 对字节流必须自行恢复行边界，对周期输出必须把输入事件与时钟节拍解耦。
• waitpid 应在通信完成后回收子进程，而不是阻塞在通信之前。

简化题意：维护一个小型 C REPL。用户可以先输入函数定义，把它们加入当前进程的符号环境；之后再输入表达式，程序把表达式包装成函数、动态编译、动态装载并执行，输出结果。

Lab 4: crepl 与动态链接接口笔记

1. 这题真正要做的事

这题表面上像“解释器”，但实现上并不是自己解析并执行 C 表达式，而是把 gcc 和动态链接器当作后端：

1. 用户输入函数定义。
2. 程序生成临时 .c 文件。
3. 调用 gcc -shared -fPIC 编译出 .so。
4. 用 dlopen 把 .so 加入当前进程。
5. 用户输入表达式时，再生成一个只包含 wrapper 的临时 .so。
6. 用 dlsym 找到 wrapper 函数地址并调用，得到表达式值。

所以核心不变式是：

• 已定义函数必须能被后续函数和后续表达式看到。
• 语法错误、未定义符号、编译失败都要被识别出来，而不是默默返回成功。

2. 整体运行模型

可以把 crepl 理解成“进程内不断扩展的符号环境”：

用户输入函数定义
  -> 生成临时 temp.c
  -> gcc -shared -fPIC temp.c -o tempN.so
  -> dlopen(tempN.so, RTLD_NOW | RTLD_GLOBAL)
  -> 新函数加入当前进程的全局符号环境

用户输入表达式
  -> 生成临时 expr.c
  -> expr.c 中写入历史函数原型 + wrapper
  -> gcc -shared -fPIC expr.c -o exprN.so
  -> dlopen(exprN.so, RTLD_NOW | RTLD_GLOBAL)
  -> dlsym(handle, "expr")
  -> 调用 expr() 得到结果

这里有两层“可见性”：

• 编译期可见性：新 .c 文件里要有旧函数的声明，不然编译器不知道 test_func() 的类型。
• 运行期可见性：旧函数所在 .so 必须已经被 dlopen(..., RTLD_GLOBAL) 加入全局环境，不然新库装载时找不到符号。

3. compile_and_load_function() 的过程

compile_and_load_function() 的任务不是“存字符串”，而是把这段函数定义真正变成当前进程里可用的符号。

典型过程：

1. 打开临时 temp.c。
2. 把历史函数原型写进去。
3. 把本次函数定义写进去。
4. fork 出子进程。
5. 子进程 execve("/usr/bin/gcc", argv, environ) 执行：

   gcc -shared -fPIC temp.c -o tempN.so
   

6. 父进程 waitpid 等编译结束。
7. 若编译成功，则 dlopen(tempN.so, RTLD_NOW | RTLD_GLOBAL)。
8. 成功后从函数定义里提取函数原型，保存给后续代码生成使用。

这里“保存函数原型”不是为了调用，而是为了后面生成新 .c 文件时补声明，例如：

int f(int x);
int g() { return f(42); }

4. evaluate_expression() 的过程

表达式不能直接 dlsym，因为 dlsym 找的是符号地址，而不是“裸表达式”。
所以表达式必须先被包装成一个真正的函数。

例如用户输入：

test_eval() / 2

需要临时生成类似：

int test_eval();
int expr() { return test_eval() / 2; }

然后流程与定义函数类似：

1. 写临时 expr.c。
2. gcc -shared -fPIC expr.c -o exprN.so。
3. dlopen(exprN.so, RTLD_NOW | RTLD_GLOBAL)。
4. dlsym(handle, "expr") 得到函数指针。
5. 调用 expr()，把返回值写进 *result。

这里 wrapper 最关键的一点是：必须 return expression;，否则函数返回值未定义。

5. 关键接口

5.1 装载共享库：dlopen

void *dlopen(const char *filename, int flags);

本实验里最重要的 flags：

• RTLD_NOW：现在就解析符号，失败立刻暴露。
• RTLD_GLOBAL：把这个库导出的符号放进全局可见环境，供后续新库使用。

如果前面定义了：

int f() { return 42; }

后面定义：

int g() { return f() + 1; }

那么 f 所在的库必须是 RTLD_GLOBAL 加载的，否则装载 g 时可能找不到 f。

5.2 查找 wrapper：dlsym

void *dlsym(void *handle, const char *symbol);

用法：

int (*fun)() = dlsym(handle, "expr");

这里 expr 必须是你生成的 wrapper 名字。
dlsym 找到的是符号地址，所以表达式必须先包成函数。

5.3 错误信息：dlerror

char *dlerror(void);

当 dlopen 或 dlsym 失败时，它能给出“未定义符号”“库打不开”等人类可读错误信息。
调动态链接问题时很有用。

5.4 行编辑和历史：readline / add_history

char *readline(const char *prompt);
void add_history(const char *line);

作用：

• readline 提供可编辑输入行。
• add_history 把输入加入历史，之后上下键才能翻。

注意：

• 只有 readline() 不够；不调用 add_history()，上下键没有历史可翻。
• 链接时还需要 -lreadline。

6. Makefile 与链接

本实验的主程序本身要链接：

• -ldl：为了 dlopen / dlsym
• -lreadline：为了 readline / add_history

它们本质上属于链接选项，应放进 LDFLAGS，而不是混在只管编译参数的 CFLAGS 里。

7. 本地测试思路

这题的本地验证可以分三层：

1. 能否编译 crepl 本身：

   make clean
   make
   

2. 手动 REPL 冒烟：

   int f() { return 42; }
   f()
   21 + 21
   int g() { return f() / 2; }
   g()
   undefined_function()
   21 +
   

3. 运行 tests.c 里的 UnitTest

   • 这些测试会直接调用 compile_and_load_function() 和 evaluate_expression()。
   • 如果 main() 是无限 REPL，测试触发方式要额外处理，否则程序不会自然退出。

8. 这次实现里踩过的坑

• 把所有动态库都输出到同一个固定路径，如 /tmp/tmp.so 或 /tmp/expr.so，导致 dlopen 复用旧对象，新代码没有真正装入。
• 把共享库路径写成 .c，把源码文件和 .so 混淆。
• execve("usr/bin/gcc", ...) 少了开头的 /；execve 不帮你查 PATH。
• 子进程 execve 失败后没有立刻 _exit(...)，导致失败路径被误当成功路径继续执行。
• 写完临时 .c 后没 fclose 就编译，结果 gcc 读到半截文件。
• 只保存了旧函数的存在，却没在新生成的 .c 文件里写旧函数声明，导致编译期找不到 test_func() 的类型。
• 误以为“之前已经 dlopen 过函数库”就不需要声明；实际上编译期声明和运行期符号解析是两回事。
• 表达式 wrapper 写成 int expr(){ expression; }，忘了 return，函数返回值未定义。
• dlsym 要找的是函数名，不是裸表达式；所以必须显式生成 expr() 之类的 wrapper。
• 在字符串拼接时只覆盖 _buffer，导致前序函数原型没真的写进临时源码。
• 以为用了 readline 就天然支持上下键历史；实际上还要 add_history()。
• 头文件加上了 readline，但 Makefile 没加 -lreadline，最终报 undefined reference to readline。

9. 总结

• 这题的本质不是“自己实现 C 解释器”，而是“把编译器和动态链接器接成一个 REPL”。
• gcc -shared -fPIC 负责把输入代码变成共享对象。
• dlopen(..., RTLD_NOW | RTLD_GLOBAL) 负责把函数定义累积进当前进程的符号环境。
• dlsym 负责从表达式 wrapper 中找到真正可调用的函数入口。
• 编译期声明和运行期符号可见性必须同时满足，才能让“后定义代码调用先定义函数”稳定成立。

1. 实验目标

本实验要实现 mymalloc(size_t size) 和 myfree(void *ptr)，用自己的 allocator 替代 glibc malloc/free，并在多线程测试中保证正确性和尽量好的性能。

allocator 的核心任务不是“调用一次系统接口返回一块内存”，而是：

1. 从 vmalloc 得到页级别的大块内存。
2. 在 allocator 内部切分成用户需要的小块。
3. 维护元数据，使 free(ptr) 能找回这块内存的来源、大小和复用方式。
4. 在多线程下保护内部状态，避免链表破坏、重复分配、数据竞争和死锁。
5. 通过拆锁、分类、缓存等方式降低同步开销。

几个最基础的接口结论：

• mymalloc(s) 只需要返回至少能容纳 s 字节的 payload，不需要刚好 s 字节。
• 内部大小可以按 8 字节、size class 或 page size 向上取整。
• vmalloc(NULL, length) 返回页级别内存，length 应该按 4096 对齐。
• vmfree(addr, length) 也应该按页级别归还，不能把 allocator 内部切出来的小块直接 vmfree。

因此，本实验的正确性不变量可以概括为：

任意时刻：
  一个字节要么属于某个已分配 payload，
  要么属于 allocator 管理的 free block / free slot，
  不能同时属于两个用户分配，
  也不能丢失到 allocator 无法再次管理的状态。

2. 最关键的工程动作：中间结果落盘

这次实验真正有效的做法不是“一口气写最终 allocator”，而是把每个阶段的中间结果落盘。

原因是 allocator 的错误经常不是普通 WA，而是：

• 随机段错误。
• 链表被破坏后过很久才爆炸。
• 多线程下偶发死锁。
• free 后复用错误。
• benchmark 卡死。
• 正确性测试通过但性能差几个数量级。

如果只保留最终代码，很多关键经验都会丢失：为什么大锁版本是必要的、为什么 per-node lock 不适合、为什么 slot 初始化会炸、为什么 thread-local cache 提升明显。

因此整个过程应该保留这些阶段产物：

这个“中间结果落盘”是 allocator 实验里的关键一刀。它把调试过程从“凭记忆试错”变成了“有阶段检查点的系统演进”。

3. 阶段一：一把全局大锁的正确性版本

最初的实现目标不是性能，而是保证最小 allocator 语义成立。

大锁版本的模型：

mymalloc:
  lock(global)
    在 free list 找可用块
    找不到则 vmalloc 新页
    必要时 split
  unlock(global)

myfree:
  lock(global)
    通过 ptr 回退到 block header
    插回 free list
    尝试 coalesce
  unlock(global)

此时数据结构可以只有一个全局 free list：

struct Node {
    struct Node *pre, *nxt;
    size_t size;
};

每个大块的内存布局：

+----------------+----------------------+
| Node metadata  | user payload         |
+----------------+----------------------+
^                ^
block start      returned pointer

用户拿到的是 Node 之后的地址；释放时用：

Node *node = (Node *)((char *)ptr - sizeof(Node));

找回块头。

这一版要先确认以下不变量：

• free list 中只保存空闲块。
• 已分配块不在 free list 中。
• split 后剩余部分仍然是合法 Node。
• coalesce 只合并物理地址相邻的空闲块。
• 所有链表修改都在同一把锁下完成。

这一阶段落盘的意义：即使后续所有性能优化都失败，也仍然有一个语义正确的版本可以回退。

4. 阶段二：地址有序 free list 与 split/coalesce

free-list allocator 的关键不是“有一个链表”，而是链表顺序要服务于 coalesce。

如果链表按地址递增维护：

free block A -> free block B -> free block C
地址也满足 A < B < C

插入一个释放块时，只要检查它的前驱和后继就能判断能否合并：

is_adj(prev, p)
is_adj(p, next)

物理相邻的判断应该是字节地址判断：

(char *)a + a->size == (char *)b

这一点非常重要。早期如果维护的是逻辑区间 [l, r)，但它不对应真实地址，就无法可靠判断两个块是否真的相邻。allocator 管的是虚拟地址空间中的真实区间，不是抽象编号。

分配时的 split 逻辑：

原空闲块:
+-------------------------------+
| size                           |
+-------------------------------+

切出 len:
+---------------+---------------+
| allocated len | remainder      |
+---------------+---------------+

只有当 remainder 足够容纳 Node 和最小 payload 时才 split。否则整块给用户，避免产生无法管理的碎片。

这一阶段主要解决：

• free 后内存能复用。
• 相邻 free block 能合并。
• 大块分配不会无限向系统申请新页。

5. 阶段三：从全局锁拆到 size-class 锁

全局锁的瓶颈非常直接：

所有线程、所有大小的 malloc/free 都抢同一把锁。

即使线程 A 申请 32B，线程 B 申请 4096B，它们也完全串行。

第一步拆锁不是给每个节点一把锁，而是按大小分类：

static Node head[20], tail[20];
static int if_init[20];
static spinlock_t list_lock[20];

每个 size class 有自己的 free list 和锁。

这样做的正确性边界比较清晰：

• 某个 class 的链表只能在持有 list_lock[class] 时修改。
• 一个 free block 在任意时刻只能属于一个 class。
• split、remove、insert、coalesce 必须在同一把 class 锁内完成。
• 尽量避免一次操作持有多把 class 锁。

这里踩过的坑是：如果当前 class 找不到块，就向更大的 class 借块，可能带来跨 class 锁顺序问题。

例如：

线程 A: 持有 class 1，等待 class 2
线程 B: 持有 class 2，等待 class 1

这就是死锁。

因此当前实现选择了更稳的路线：大块按 getid(size) 进入一个 class，主要在本 class 内申请和回收。这样可能牺牲一点全局利用率，但锁协议简单很多。

6. 为什么小对象要换成 slot/span

free list 对大块合适，但对小对象不合适。

如果 24B 对象也走 Node + payload：

+----------------+----------+
| Node metadata  | 24B user |
+----------------+----------+

问题有三个：

1. 元数据占比太高。
2. 小对象分配频率极高，链表操作太频繁。
3. 多线程同 class 小对象会高频抢锁。

所以小对象更适合固定大小 slot：

32B class:
  24B 请求 -> 32B slot
  slot 内没有完整 Node header

大对象仍适合 free list，因为大对象大小差异大，保留 split/coalesce 能减少外部碎片。

因此当前最终结构是混合 allocator：

size <= 2048:
  slot/span allocator

size > 2048:
  size-class free-list allocator

7. 阶段四：span 管理

当前小对象路径使用 span。

一个 span 是一页 4096B：

#define SPAN_SIZE 4096

span 结构：

struct span {
    size_t class_id;
    size_t cap;
    size_t size;
    int magic;
    void *free_list;
    struct span *nxt;
};

含义：

• class_id：这个 span 属于哪个 size class。
• cap：这个 span 中最多有多少 slot。
• size：当前已经分配出去的 slot 数量。
• magic：用于在 free(ptr) 时判断它是不是 slot 分配。
• free_list：span 内部空闲 slot 链表。
• nxt：挂到 class 的 span 链表中。

span 内存布局：

4096B span

+----------------------+---------+---------+---------+-----+
| span metadata         | slot 0  | slot 1  | slot 2  | ... |
+----------------------+---------+---------+---------+-----+
^                      ^
span base              first aligned slot

空闲 slot 自己的开头存 next 指针：

free slot:
+----------------+
| next pointer   |
+----------------+

allocated slot:
+----------------+
| user data      |
+----------------+

所以“一个 slot 是否被占用”的判断不是靠单独 bitmap，而是：

如果它在 span->free_list 链上，就是空闲；
如果它不在 free_list 链上，就视为已分配。

当前 size class：

const size_t SIZE[] = {32, 64, 128, 256, 512, 1024, 2048};

这对应一个简化版 slab/slot allocator。

8. 阶段五：thread-local cache

slot/span 解决了小对象元数据问题，但如果每次 malloc/free 仍然拿全局 class 锁，多线程性能还是上不去。

因此加入每线程缓存：

struct threadcache {
    void *list[CLASS_NUM];
    size_t count[CLASS_NUM];
};

static thread_local threadcache tcache;

分配路径：

slot_malloc(size):
  class = getclass(size)

  if 本线程 tcache[class] 非空:
    直接 pop 一个 slot
  else:
    lock(global class)
      批量取 CACHE_BATCH 个 slot
      放入 tcache[class]
    unlock(global class)
    pop 一个 slot 返回

释放路径：

slot_free(ptr):
  找到 ptr 所在 span
  得到 class_id
  push 到本线程 tcache[class]

  if tcache[class] 太满:
    lock(global class)
      批量 flush 一部分 slot 回 span
    unlock(global class)

这个优化的本质：

无 thread cache:
  每次小对象 malloc/free 都抢全局锁

有 thread cache:
  大多数 malloc/free 只操作本线程链表
  偶尔 refill/flush 才抢全局锁

这是当前性能提升最明显的一步。

代价也很明确：

• 每个线程会暂存一些空闲 slot，增加内存滞留。
• 线程退出时如果不 drain，本地 cache 中的 slot 不会及时回到全局结构。
• batch 太小锁竞争多，batch 太大内存滞留多。

当前实现使用：

#define CACHE_BATCH 32
#define CACHE_VOLUM 64

这是一个经验参数，不是理论最优。

9. 当前最终 allocator 结构

当前代码可以概括为：

mymalloc(size)
|
+-- align8(size)
|
+-- size <= 2048
|   |
|   +-- slot_malloc
|       |
|       +-- thread-local cache
|       +-- global class lock
|       +-- span available/full list
|       +-- vmalloc new span if needed
|
+-- size > 2048
    |
    +-- list_malloc
        |
        +-- size-class lock
        +-- address ordered free list
        +-- find first enough block
        +-- split
        +-- vmalloc new page block if needed

myfree(ptr) 的分类逻辑：

page-align ptr -> possible span base

if span->magic == SPAN_MAGIC:
  slot_free(ptr)
else:
  list_free(ptr)

这是一种实用但不完美的分类方式。

优点：

• slot 没有 per-object header，节省小对象元数据。
• 通过页对齐可以快速找到 span metadata。

限制：

• 依赖 span 由 4096 对齐页构成。
• 依赖大块路径不会在对应位置偶然出现相同 magic。
• 更工程化的实现通常会使用 page map、arena map 或统一 header 来区分来源。

10. 本地测试系统

课程自带测试对并发 allocator 来说偏弱，尤其是之前看到的 concurrent test 主要检查 malloc_count，不等价于真正验证内存不重叠、free 后复用、多线程随机行为都正确。

因此额外写了本地测试系统，落盘在：

/home/katyusha/vibe

测试系统包括：

• 基本边界测试：0、1、小对象、跨 class、大对象。
• 重复分配释放测试：检查复用。
• coalesce 测试：检查释放相邻块后能否合并。
• single-thread random：随机大小、随机释放顺序。
• multi-thread random：多线程随机 malloc/free。
• perf-only：吞吐量 benchmark。
• glibc baseline：同一套 workload 下对比 glibc malloc。

这个测试系统的意义是把“我感觉可以”变成“有本地证据”。

尤其是性能优化时，不能只说“拆锁会更快”，而要看：

single small
single medium
page-ish
threads same class
threads spread classes

分别有什么变化。

11. 性能结果与解释

一次较新的 benchmark 结果大致为：

glibc malloc:
  single small 24B              约 166 Mops/s, 约 6 ns/op
  single medium 512B            约 112 Mops/s, 约 9 ns/op
  single page-ish 4096B         约 0.58 Mops/s, 约 1724 ns/op
  threads same class 32B        约 206 Mops/s, 约 4.9 ns/op
  threads spread classes        约 100 Mops/s, 约 10 ns/op

current mymalloc:
  single small 24B              约 90 Mops/s, 约 11 ns/op
  single medium 512B            约 52 Mops/s, 约 19 ns/op
  single page-ish 4096B         约 2.7 Mops/s, 约 369 ns/op
  threads same class 32B        约 68 Mops/s, 约 15 ns/op
  threads spread classes        约 29 Mops/s, 约 35 ns/op

这个结果说明：

• 小对象已经不再是灾难级性能，slot + thread cache 有效。
• 中等对象仍弱于 glibc，主要差在 class 管理、cache 策略和元数据路径。
• 4096B 附近反而比 glibc 快，可能是测试 workload 下当前路径更直接。
• 多线程 spread classes 仍明显弱于 glibc，说明全局 class 锁、span 链表和 refill/flush 策略还有优化空间。

更重要的是，性能结果证明了中间版本落盘的价值：如果没有大锁 baseline、free-list 版本、slot 版本、thread-cache 版本，就无法判断性能提升来自哪一步。

12. 主要踩坑

12.1 vmalloc 不是输出参数

错误理解：

vmalloc 把结果写进传入指针

正确理解：

void *p = vmalloc(NULL, length);

它直接返回地址。

并且 length 应该是 4096 的倍数。不能对 split 出来的小块调用 vmfree。

12.2 mymalloc(s) 不要求精确返回 s 字节

真实 allocator 都会有对齐和 size class。

因此：

mymalloc(24) 返回 32B slot 是合法的。

只要用户能安全访问前 24B 即可。

12.3 链表必须基于真实地址

coalesce 依赖物理相邻。

所以链表中块的范围必须对应真实地址，而不是抽象编号。

正确模型：

block_start + block_size == next_block_start

12.4 指针运算容易产生 UB 或 GNU C 依赖

典型错误：

Node *p;
p + sizeof(Node);   // 错：按 Node 为单位移动

应该写成：

(char *)p + sizeof(Node)

当前代码中仍有一些 void * 指针算术和 unsigned long long 地址转换。它们在 GNU C 下通常可工作，但更严谨的写法应该使用：

char *
uintptr_t

分别处理字节指针和整数地址。

12.5 per-node lock 不适合当前 allocator

曾考虑过每个链表节点一把锁：

查找进入节点时加锁
离开时释放
插入/删除时同时锁前驱、当前、后继

问题是：

• 节点可能被 split 或 coalesce 后消失。
• 其他线程可能还想访问这个节点的锁，生命周期很难管理。
• 同时锁多个节点需要严格锁顺序，否则死锁。
• allocator 链表操作很短，per-node lock 的开销和复杂性不划算。

所以更稳定的拆锁方向是 size-class lock，而不是 node lock。

12.6 跨 class 借块会引入锁顺序问题

如果 class A 没有空间就去 class B 找，会出现多锁操作。

除非全局规定严格锁顺序，否则容易死锁。

当前实现避免跨 class 借块，是为了保持锁协议简单。

12.7 slot 初始化边界错误会导致随机段错误

span 切 slot 时必须保证：

slot_start + slot_size <= span_start + SPAN_SIZE

常见错误：

• next 指针写到了页外。
• s + slot_size 把 span * 当字节指针。
• 最后一个 slot 的 next 没有置空。
• 用 unsigned 保存指针导致 64 位地址截断。
• 第一个 slot 没有按 8 字节对齐。

这类错误很隐蔽，因为第一次分配可能没问题，等 free-list pop 到坏指针时才段错误。

12.8 空 span 不能轻易立刻 vmfree

理论上 span 全空后可以还给系统。

但当前有 thread-local cache 后，某些 slot 可能还滞留在线程本地 cache 中。如果直接 vmfree(span)，cache 中的 slot 就变成悬垂指针。

因此当前版本注释掉了积极归还 empty span 的逻辑，选择先保留 span 复用。

这是一个合理的阶段性选择：先保证正确性和性能，再做更复杂的 span 生命周期管理。

13. 当前代码仍需注意的问题

当前版本已经通过本地正确性测试，并且性能相比早期版本有明显提升，但还有几个工程上不够干净的地方：

1. void * 指针算术依赖 GNU C 扩展，应改成 char *。
2. 地址整数转换应优先用 uintptr_t，而不是 unsigned long long。
3. magic 分类方式有小概率误判风险，最好用 page map 或统一 metadata。
4. getclass 对大于 2048 的路径没有显式返回，虽然调用方已经过滤，但函数本身不够完整。
5. thread-local cache 没有在线程退出时 drain。
6. span 的 full/available 链表移动仍然有线性查找。
7. 大块 free list 仍是 first-fit 线性扫描。
8. malloc_count 虽是 atomic，但它更像测试辅助变量，不应参与 allocator 核心设计。

这些不是当前实验一定要全部解决的问题，但应该在笔记里保留，防止以后把“能过测试”误认为“已经工程完备”。

14. 后续优化方向

后续如果继续优化，可以按风险从低到高推进：

1. 清理 UB：统一使用 char * 和 uintptr_t 做地址计算。
2. 调整 size class：根据 benchmark workload 优化 class 分布。
3. 调整 CACHE_BATCH 和 CACHE_VOLUM：平衡锁竞争和内存滞留。
4. 给 span 增加更清晰状态：empty、partial、full。
5. 建立 page map：通过页号直接找到 span 或大块 metadata。
6. 支持线程退出时 drain thread-local cache。
7. 大块路径使用更好的数据结构，例如 segregated list 更细分或 tree。
8. 增加更强 stress：跨线程 free、长时间随机 trace、ASan/UBSan、重复 benchmark。

15. 总结

这次 allocator 的完整路线是：

全局大锁 baseline
  -> 地址有序 free list
  -> split/coalesce
  -> size-class lock
  -> 小对象 slot/span
  -> thread-local cache
  -> 本地 correctness + perf 测试系统
  -> 写入实验笔记复盘

其中最重要的不是某个具体技巧，而是阶段化方法：

先做正确版本；
再拆锁；
再分类；
再缓存；
每一步都落盘；
每一步都用测试验证。

allocator 的难点在于它维护的是一套隐式状态机：每块内存不断在 “系统页”、“free block”、“allocated payload”、“free slot”、“thread cache slot” 等状态之间转换。只要某次状态转移没有被锁保护，或者元数据没有同步更新，错误就可能在很久之后才出现。

当前版本已经具备现代 allocator 的简化雏形：

• 大对象用 free list 管理，支持 split 和 coalesce。
• 小对象用 span/slot 管理，降低元数据开销。
• 多线程用 thread-local cache 减少锁竞争。
• 本地测试系统用于验证正确性和性能。

这比单纯完成 lab 更重要：它把 malloc 从一个 API 练习，推进到了 runtime memory manager 的设计问题。

应用视角的操作系统

应用视角的操作系统是一组 API：进程、地址空间、文件描述符、内存映射等资源都通过系统调用访问。

程序

Everything is a state machine：一切都是状态机。

硬件状态可以粗略看成：

(registers, memory)

CPU 执行指令，就是把状态迁移到下一个状态。用户态程序也类似：

用户态寄存器 + 用户虚拟地址空间 + OS 维护的进程状态

虚拟地址空间包含代码段、只读数据、全局变量、堆、栈、mmap 区域等。

注意：PC/RIP 是寄存器，不在栈顶。CPU 根据 PC/RIP 取下一条指令；栈上主要保存返回地址、局部变量、保存的寄存器等函数调用状态。

程序也不是从 main 直接开始。Linux 执行 ELF 时大致是：

execve
  -> 内核加载 ELF，建立地址空间
  -> 准备初始用户栈：argc / argv / envp / auxv
  -> 设置 RIP = ELF entry，通常是 _start
  -> _start 初始化运行时，再调用 main

所以：

_start 是进程真正入口；
main 是 C/C++ 运行时调用的普通函数。

函数调用通常会创建栈帧，但这是 ABI/编译器约定；优化后可能内联、尾调用、省略帧指针，因此不能把“每个函数一定有一个栈帧”当成语义保证。

C 可以改写成“每行只做一件事”的 Simple C 风格，因此接近机器模型；但现代 C 不是简单的高级汇编，它有 UB、别名规则、对象生命周期和优化语义。

编译器

早期编译器可以近似理解为直接翻译语句；现代编译器会在保持可观察行为不变的前提下激进优化。

编译正确性：

对任意符合语言语义的输入，编译后程序与源程序具有相同的可观察行为。

可观察行为包括程序终止性、volatile 访问、I/O、系统调用产生的外部效果、与外部函数/ABI 的交互等。

如果计算结果不影响可观察行为，编译器可以删除它；但 write/read/mmap/exit 这类有外部副作用的调用不能被当作普通算术随意删除、合并或重排。

系统调用相关优化要分层：

编译器：可能优化 printf("x\n") 这类库调用形式
libc：通过 stdio buffering 减少 write 次数
内核：执行 syscall 后走具体内核路径

系统调用指令

最小的 hello world 不是在 main 中调用 printf，而是从 _start 开始直接执行：

write(1, "hello world\n", 12)
exit(0)

Linux x86-64 系统调用 ABI：

rax = syscall number
rdi/rsi/rdx/r10/r8/r9 = args
syscall

write() 是 C 库函数，真正进入内核的是 syscall 指令。

用户态程序直接能做的事情：

改变用户态可见寄存器状态；
读写自己有权限的虚拟内存；
通过 syscall/ecall/svc 请求内核服务。

系统调用会把状态机暂时交给 OS：CPU 切到内核态，内核检查参数和权限，执行服务，再返回用户态；exit 这类系统调用可能不返回。

程序也可能通过异常被动进入内核，例如缺页、除零、非法指令、非法地址访问。非法内存访问通常最终变成 SIGSEGV。

应用、工具程序、后台程序

用户态程序大致包括：

Applications：浏览器、IDE、播放器等面向用户任务的程序
Utilities：ls、cat、cp、mv、rm、sort、wc 等工具程序
Daemons：systemd、sshd、cron 等长期运行的后台服务

它们本质上都是：

用户态计算 + 系统调用

coreutils 是 GNU 提供的一组基础命令行工具集合，例如 ls/cat/cp/mv/rm/mkdir/wc/sort/date/sleep。它不是“系统调用薄包装”的泛称，而是一批标准工具程序；这些程序内部通常调用 libc/POSIX API，最终落到系统调用。

典型例子：

cat file -> openat/read/write/close
ls       -> openat/getdents64/stat/write

daemon 也是普通用户态进程，只是长期运行、通常没有交互式终端，用来提供系统服务。

Linux 下可以用 strace 观察程序发出的系统调用；它看到的是用户程序和内核之间的 syscall 边界，而不是所有普通用户态指令或 libc 内部细节。

硬件视角的操作系统

硬件根本不知道有没有操作系统。从硬件看，OS 首先也只是会被 CPU 执行的一段程序；机器只关心状态、初始状态和状态迁移。

计算机的状态机模型

最简模型是：

(registers, memory)

CPU 每执行一条指令，就是把当前状态迁移到下一个状态；PC/RIP 决定下一条从哪里取指。

但只看寄存器和内存还不够，因为真实计算机不是封闭系统。还要加入“外部世界”：I/O 设备，中断线，GPIO 这类最基础的设备引脚等

CPU 和设备通信的典型方式有两种：

• port I/O：例如 x86 的 in/out
• MMIO：把设备寄存器映射到物理地址空间，像访存一样读写GPIO 就是最简单的 MMIO 设备之一

对多处理器系统，可以先用一个简化模型理解：

每个 CPU 有自己的寄存器；
处理器之间共享内存和外设；
系统的执行像是在多个 CPU 之间交错选择一步。

这个模型足够建立直觉；但真实机器上还会叠加 cache、乱序执行和 memory model，因此并发行为会比“轮流单步执行”复杂得多。

硬件的初始状态

reset 不是普通中断。中断的语义是“打断当前控制流，保存现场，处理完再回来”；reset 的语义是“当前上下文作废，硬件强制回到定义好的初始状态重新开始”。

这就是为什么老式机器常有 reset 按钮：系统可能已经因为内核、驱动或硬件状态异常而不再可靠响应，中断也未必救得回来，只能丢弃当前状态重启。

固件

断电后 RAM 内容可能丢失，但如果不加处理，reset 后 CPU 的第一条指令会来自那片不可信的 RAM，导致执行非法指令。

所以reset 后不是从随机 RAM 开始跑，而是从预先约定好的启动入口取指，这个过程由固件firmware控制。

firmware 是 reset 后第一个执行的软件，它可以看作“OS 之前的 OS”。

CPU reset
  -> PC 指向 firmware
  -> firmware 初始化最小硬件环境
  -> 初始化 DRAM / 检测设备
  -> 加载后续 bootloader / kernel

早期 OS能力弱， firmware 往往还长期提供运行时服务；现代系统里，OS 启动后通常会尽快接管设备和资源管理，firmware 更多只负责引导和少量平台服务。

BIOS和UEFI是firmware的两种实现标准，其中后者是一种更现代的，更模块化的架构替代

BIOS 是传统 PC 固件：16 位实模式、接口简单、历史包袱重。IBM PC 的经典启动流程是：

BIOS 扫描启动设备
  -> 读取启动盘前 512B 到 0x7c00
  -> 检查末尾魔数 0x55AA
  -> 跳转到 0x7c00 执行

UEFI 则不是“更大的 BIOS 中断库”，而是一套更完整的固件执行环境和启动规范。它通常能直接识别分区和文件系统，加载 .efi 程序；本质上更像一个最小固件操作环境。

从 OS 视角，BIOS 和 UEFI 的共同点比差异更重要：

可以把整个启动链压缩成：

CPU Reset -> Firmware -> Bootloader -> Kernel -> 第一个用户进程 

补充：CIH病毒通过获取足够高的权限，对firmware进行写，导致机器无法启动

并发 bug 的统一模型是：程序员在脑中假设了一种执行顺序，但真实机器允许更多 interleaving、重排和可见性延迟。
所以修 bug 的核心不是“多加几把锁”，而是把隐含顺序显式写成同步约束：

共享状态 + 不变量 + happens-before

只要一个并发程序不能说清楚“哪些状态由谁保护、哪些事件必须先发生”，它就只能靠调度运气运行。

并发错误的根源

顺序程序可以近似看成：

state_{i+1} = f(state_i)

多线程程序则多了一层调度选择：

1. 每个线程内部仍保持局部顺序
2. 全局执行由多个线程的局部步骤交错而成
3. 编译器和处理器还可能在内存模型允许范围内重排

因此，课堂里把并发 bug 叫做 Learning from Mistakes：不是因为 API 难，而是因为人的顺序直觉会自动补全一些机器没有承诺的东西。

典型错误都可以归结为某种错误假设：

• 死锁：以为“我最终能拿到所有资源”。
• 数据竞争：以为“别人不会同时访问这个内存位置”。
• 原子性违反：以为“check 和 act 之间不会插入别的线程”。
• ABA：以为“值还是 A 就说明状态没变过”。
• TOCTOU：以为“检查完之后对象不会被替换”。
• 顺序违反：以为“代码顺序就是其他线程观察到的顺序”。

死锁的基本模型

Deadlock 是一种系统状态：一组线程里的每个成员都在等待组内另一个成员采取行动，甚至可能是等待自己。

最小例子是 AA 型死锁：

mutex_lock(&A);
mutex_lock(&A); // 非递归 mutex: 自己等自己

这看起来像是显然不会写出的错误，但真实代码里第二次加锁可能藏在 callback、递归、错误处理路径或多层封装里。只要 pthread_mutex_t 是普通非递归锁，同一线程第二次 lock 就会阻塞在自己持有的锁上。

另一个经典形态是 ABBA 型死锁：

// Thread 1
mutex_lock(&A);
mutex_lock(&B);

// Thread 2
mutex_lock(&B);
mutex_lock(&A);

如果 T1 持有 A 等 B，T2 持有 B 等 A，等待图中出现环，两个线程都无法推进。哲学家吃饭问题就是 ABBA 的环形推广：每个人都拿了左手叉子，然后等待右手叉子。

死锁的四个必要条件

Coffman 等人在 1971 年总结了死锁的四个必要条件。关键是“必要条件”的含义：四条必须同时成立，死锁才可能发生；打破任意一条，死锁就不会发生。

1. Mutual Exclusion: 资源互斥占用
2. Wait-For: 持有已有资源，同时等待更多资源
3. No Preemption: 资源不能被外部强制抢走
4. Circular Wait: 等待关系形成环

这四条不是“满足就一定死锁”的充分条件，而是“死锁发生时一定满足”的必要条件。很多网上速记会把这个逻辑讲反。

对应到代码：

• AA 死锁主要暴露的是 wait-for：线程已经持有 A，却又等待 A。
• ABBA 死锁主要暴露的是 circular wait：A -> B 与 B -> A 构成环。
• 哲学家吃饭问题暴露的是多节点 circular wait。

破坏死锁条件的方法

所有死锁治理都可以映射回“打破四条件”。

破坏互斥占用

有些资源天生互斥，例如锁保护的共享数据结构、独占设备、文件写入位置。
这条通常最难破坏，因为它本来就是资源正确性的来源。能做的优化往往是减少共享状态，或者把共享资源改成可复制、可合并的结构。

例如并行 reduce 中，每个线程使用私有局部累加器，最后再合并，就相当于减少了对同一个共享计数器的互斥需求。

破坏持有并等待

最直接的方法是一把大锁：

mutex_lock(&global);
// 一次性访问所有共享状态
mutex_unlock(&global);

这样线程不再“持有 A 等 B”，因为它只需要获取一个全局资源。
缺点也明显：并行度会被大锁压扁，临界区占比变大后，Amdahl 瓶颈会非常硬。

另一种思想是 transactional memory：把一段共享内存操作当成事务执行，语义上要求 all or nothing。

atomic {
    A -= 100;
    B += 100;
}

事务内存的模型是：先乐观执行，记录 read set / write set，提交时检查冲突；无冲突则一次性提交，有冲突则 abort 并回滚重试。
它试图避免程序员手动管理多把锁的顺序，从而降低 wait-for 和 lock ordering 的复杂度。

但它难实现，也不能覆盖所有副作用：

• I/O、系统调用、打印、网络发送通常无法自然回滚。
• HTM 受 cache 容量、中断、调度、系统调用限制，可能无冲突也 abort。
• STM 需要软件维护日志、版本号和回滚，开销较大。
• 事务反复 abort 可能导致活锁或饥饿。

所以它是理解“all or nothing 临界区”的好模型，但不是工程里的万能替代品。

破坏不可抢占

如果系统能在发现危险时撤销某个线程的资源持有，就可以破坏 no-preemption。数据库事务常用这种方式：检测到死锁后选择一个事务 abort，释放它持有的锁，让其他事务继续。

在普通 C/Pthreads 程序里，这很难，因为线程持有锁时可能已经修改了复杂共享状态、执行了不可回滚的 I/O，外部很难安全地“抢锁”。
因此普通 mutex 世界里更常见的是预防锁顺序问题，而不是运行时强行回滚线程。

破坏循环等待

工程上最常用的方法是 lock order：给所有锁规定一个全局顺序，所有线程必须按同一顺序加锁。

A < B < C

允许: lock(A); lock(B); lock(C);
禁止: lock(C); lock(A);

如果所有边都从低编号锁指向高编号锁，等待图就不可能形成环。这条规则非常朴素，但能处理大量 ABBA 问题。

动态死锁检测

死锁的症状通常比数据竞争明显：程序本该继续输出，突然完全静默；用 GDB attach 进去，经常能看到所有线程阻塞在 futex_wait 或 mutex lock 路径上。

但更好的目标不是等它真的卡死，而是在测试时发现潜在环。

lockdep 的核心思路是把上锁顺序转化成图：

线程当前持有 A，再请求 B => 加边 A -> B
线程当前持有 B，再请求 A => 加边 B -> A
图里出现环 => 存在潜在 ABBA 死锁

伪代码模型：

thread_local vector<mutex_t *> held;
Graph order;

void on_lock(mutex_t *m) {
    for (mutex_t *h : held) {
        order.add_edge(h, m);
    }
    if (order.has_cycle()) {
        warn("potential deadlock");
    }
    held.push_back(m);
}

讲义中还强调了 LD_PRELOAD 的做法：写一个共享库定义同名 pthread_mutex_lock/unlock，通过动态链接器优先加载我们的版本，就能在不重新编译目标程序的情况下插桩记录锁顺序。Linux 内核的 lockdep 也是同类思想的工程化版本，只是要额外处理 spinlock、rwlock、RCU、中断上下文等复杂情况。

数据竞争

数据竞争的判定条件是：

1. 至少两个线程访问同一内存位置
2. 至少一个访问是写
3. 这些访问之间没有 happens-before 关系

例如：

int x = 0;

void T1() { x++; }
void T2() { x++; }

x++ 会被拆成 load / add / store。两个线程可能都读到旧值，再分别写回，导致 lost update。
更重要的是，在 C/C++ 内存模型里，普通变量上的 data race 是 undefined behavior。编译器可以基于“无数据竞争程序”的假设优化代码，因此不能把它只理解为“结果随机一点”。

正确修复有两条主路：

• 用同一把 mutex 保护同一组共享不变量。
• 如果只是单变量原子读改写，用 atomic 并明确内存序。

锁的含义不仅是互斥，还建立 release-acquire happens-before：

T1: 写共享状态; unlock(m)
T2: lock(m); 读共享状态

unlock(m) happens-before lock(m)

所以“加锁”不是形式动作，必须保护同一个状态条件和同一组不变量。

ThreadSanitizer 的检测模型

ThreadSanitizer 通过编译期插桩和运行期记录访问历史来检测 happens-before race：

gcc -fsanitize=thread -g main.c -o main
./main

它大致维护：

• 每个线程的逻辑时间；
• 每个同步操作建立的 happens-before；
• 每个内存位置最近读写历史。

当两个访问没有 happens-before，且至少一个是写，就报告 race。
TSan 的限制也要记住：动态工具只能检查这次运行覆盖到的路径；如果错误 interleaving 没被触发，它未必能报告。

相关工具的定位：

• Eraser：早期 dynamic race detector，核心是 lockset 思想。
• Helgrind：Valgrind 套件里的线程错误检测工具，不需要重编译但慢。
• ThreadSanitizer：编译插桩，工业里更常用。
• KCSAN：Linux 内核中的并发访问检测工具。

Therac-25 的事故教训

讲义用 Therac-25 强调了一点：并发 bug 不只是输出错几个数字，它可能直接伤害现实世界中的人。

Therac-25 是一台放射治疗设备，软件需要协调操作员输入、治疗模式、靶板位置和射线剂量。事故中的关键问题可以抽象成：

UI 线程快速修改治疗模式
硬件控制线程尚未把保护装置移动到正确位置
软件却继续按“状态已经一致”的假设发射高剂量射线

这类 bug 的本质是 race condition / order violation：程序以为模式切换、硬件状态更新、剂量控制之间有可靠顺序，但代码没有用同步机制把这个顺序固定下来。
它的工程教训是：涉及设备、权限、安全边界的并发程序，不能只依赖“正常操作路径”测试；必须把异常速度、重复输入、中断、取消、回滚路径都纳入状态机验证。

原子性违反

Atomicity violation 是“程序员以为一段代码不可打断，但实际上它可以被插入别的线程”。

典型 check-then-act：

if (ptr != NULL) {
    *ptr = 42;
}

错误窗口在检查和使用之间：

T1: 读到 ptr != NULL
T2: free(ptr); ptr = NULL
T1: *ptr = 42

修复不是“多检查一次”，而是让检查和使用属于同一个临界区：

mutex_lock(&m);
while (ptr == NULL) {
    cond_wait(&cv, &m);
}
*ptr = 42;
mutex_unlock(&m);

条件变量模板之所以要求 while + cond_wait，就是为了在“条件成立且锁在手”的状态下继续执行。
这里的关键不变量是：只要线程从 while 之后继续运行，它仍持有保护 ptr 的锁，因此别的线程不能在 act 前破坏条件。

ABA 与 Use-After-Free

ABA 问题是：一个值从 A 变成 B，又变回 A；观察者只看到“还是 A”，于是误以为状态没变过。

在 CAS 和 lock-free 数据结构里很常见：

T1: 读取 top = A
T2: pop A; pop B; push A
T1: CAS(top, A, next_of_A) 成功

T1 的 CAS 只验证了“top 现在等于 A”，没验证中间有没有发生过结构变化。
Use-After-Free 也可以看成指针层面的 ABA：

T1: 保存指针 p -> 对象 X
T2: free(X)
T2: malloc 得到同一地址，构造对象 Y
T1: 继续通过 p 访问，以为是 X，实际写到 Y

防御方法通常不是简单加 atomic，而是管理对象生命周期：

• 引用计数；
• hazard pointer；
• epoch-based reclamation；
• 给指针附加版本号，CAS 比较 (ptr, version)。

也就是说，ABA 的核心是“值相等不代表语义状态相同”。

TOCTOU

TOCTOU 是 Time of Check to Time of Use：检查和使用之间存在时间窗口，对象可能被别人替换。

经典模式：

if (is_safe(path)) {
    open(path);
}

检查的是路径当时指向的对象；使用时路径可能已经被攻击者换成符号链接。讲义里提到的 sendmail 类漏洞就是：setuid root 程序先检查 mailbox 不是 symlink，随后攻击者在 check/use 窗口把它替换成指向 /etc/passwd 的 symlink，最终高权限程序写错目标。

修复原则是：不要检查一个可变名字后再用它；要拿到稳定对象句柄后检查。

例如：

int fd = open(path, O_NOFOLLOW | O_APPEND);
fstat(fd, &st);
// 后续使用 fd，而不是重新解析 path

文件描述符绑定的是内核 open file object / inode 引用；只要拿到了 fd，后续路径名怎么变，都不会把这个 fd 变成另一个文件。

顺序违反

Order violation 是：程序员假设 A 一定先于 B，但没有同步原语保证。

常见初始化发布错误：

// Thread 1
config = load_config();
ready = true;

// Thread 2
while (!ready) {}
use(config);

这里有两层问题：

• 编译器可能重排或缓存普通变量访问；
• CPU 可能让 ready 的写先于 config 对另一个核心可见。

如果 ready 和 config 都是普通共享变量，这本身还会形成 data race。正确发布需要 release-acquire：

// Thread 1
config = load_config();
atomic_store_explicit(&ready, true, memory_order_release);

// Thread 2
while (!atomic_load_explicit(&ready, memory_order_acquire)) {}
use(config);

release 的含义是：发布 ready=true 前的写入不能跑到发布之后。
acquire 的含义是：观察到 ready=true 后，后续读能看到发布者 release 前写入的状态。

如果同步条件更复杂，直接用 mutex + condition variable 往往更清晰。

防御性编程原则

并发程序的防御性编程，不是把每个地方都包一把锁，而是让状态关系可检查、可插桩、可复现。

写出共享状态的不变量

例如生产者消费者：

0 <= count <= N

例如转账：

A + B 总额不变

例如锁顺序：

所有线程只能按 A < B < C 获取锁

不变量写不出来，后面的锁、条件变量、信号量都只能靠局部直觉拼凑。

让同步边界尽量小而完整

临界区应该覆盖共享状态的检查和修改，不能只锁一半：

mutex_lock(&m);
if (balance >= x) {
    balance -= x;
}
mutex_unlock(&m);

但临界区也不应无限扩大。耗时计算、I/O、RPC、sleep 尽量放到锁外，否则会制造性能瓶颈和新的死锁机会。

默认使用工具

并发 bug 不能只靠“我想清楚了”。

• 死锁：GDB attach、线程栈、lockdep、锁顺序图。
• 数据竞争：ThreadSanitizer、Helgrind、KCSAN。
• UAF / ABA：ASan、KASAN、引用计数检查、生命周期审计。
• TOCTOU：安全审计、fd-based API、O_NOFOLLOW、权限边界检查。

动态工具不能证明无 bug，但能快速打掉大量错误假设。

不要相信测试次数

并发 bug 的触发依赖调度。一次、十次、一万次没触发，只能说明测试覆盖的 interleaving 里没出事。

更有效的测试方式是：

• 增加线程数和循环次数；
• 在关键路径插入随机 yield / sleep；
• 固定随机种子复现；
• 用 sanitizer 和断言检查不变量；
• 把“偶现错误”当作确定存在的逻辑漏洞，而不是环境噪声。

本节小结

1. 并发 bug 来自“假设的顺序”与“真实允许的执行”不一致。
2. 死锁四条件是必要条件；打破任意一个条件即可排除死锁。
3. AA 是自己等自己，ABBA 是等待图成环；lock order 是最常用防御。
4. Transactional memory 用 all-or-nothing 尝试替代手写锁顺序，但回滚和副作用很难。
5. Data race = 同一内存位置 + 并发访问 + 至少一写 + 无 happens-before。
6. TSan 用运行期 happens-before 推理检测 race，但只能覆盖实际执行路径。
7. Therac-25 说明 race / order violation 在安全关键系统里可能造成真实伤害。
8. Atomicity violation 的核心窗口在 check 和 act 之间。
9. ABA / UAF 说明“值相同”不等于“对象状态相同”。
10. TOCTOU 的修复方向是先获得稳定句柄，再检查和使用。
11. Order violation 需要 release-acquire、mutex/cv 或其他同步原语建立顺序。
12. 并发正确性最终要落回共享状态、不变量、同步边和工具验证。

第 19 讲的入口不是某个新 API，而是一个系统问题：

我们想像调用函数一样随时创建并发任务，
但 OS 线程的创建、栈空间、调度和切换都太贵。

第 18 讲已经把并行算法抽象成计算图：节点是本地计算，边是依赖或同步。第 19 讲继续追问：当计算图的节点很多、每个节点经常等待 I/O 时，是否还应该为每个节点创建一个 OS 线程？

答案通常是否定的。工程上有两条路线：

1. 让“线程”变轻：coroutine / goroutine / lightweight thread。
2. 改变执行模型：future / promise / async-await / event loop。

本笔记重点放在第一条路线和它与异步 I/O 的关系上；讲义最后的 JavaScript / Web 计算图模型暂不展开。

线程开销问题

线程的核心模型可以写成：

thread = 独立栈 + 独立寄存器上下文 + 内核调度实体 + 共享进程地址空间

它比进程轻，因为不复制整个地址空间；但它仍然不是免费的。一个 Linux pthread 至少会带来：

• 用户栈：常见默认约 8 MB 虚拟地址空间，物理页通常按需分配。
• 内核对象：调度实体、内核栈、线程元数据等。
• TLS / TCB：线程本地存储和线程控制块。
• 调度成本：阻塞、唤醒、上下文切换都要进入内核。
• 缓存扰动：线程迁移、锁竞争和共享 cache line 会破坏局部性。

所以课程里说 10000 个线程大约对应 80 GB 虚拟栈空间，这不是夸张修辞，而是在提醒：

线程的抽象很好用，但“每个并发活动一个 OS 线程”无法无限扩展。

如果 workload 中大量任务只是等待网络、管道、定时器或磁盘事件，OS 线程的大栈和内核调度就会成为主要开销。

两条工程路线

课程把问题抽象成下面的愿望：

t1 = spawn(f);
t2 = spawn(g);
t3 = spawn(h);
join(t1);
join(t2);
join(t3);

理想状态下，spawn/join 的成本应该接近函数调用；现实中，OS 线程远比函数调用重。

因此有两条路线。

第一条是轻量化线程：

保留“像线程一样写”的模型，
但把调度、栈和切换尽量搬到用户态。

典型代表是：

• Python generator。
• C++20 coroutine。
• 用户态栈切换库，如 ucontext / setjmp / longjmp / Boost.Context。
• Go goroutine。

第二条是异步编程：

不再假装每个任务都是一个阻塞线程，
而是显式描述“现在等什么事件，事件完成后继续哪一段代码”。

典型代表是：

• Future / Promise。
• async/await。
• event loop。

这两条路线表面不同，底层都在处理同一个问题：

当任务进入等待状态时，不要让整个 OS 线程傻等。

协程的基本执行模型

协程可以先抓成一句话：

coroutine = 可以主动挂起并稍后恢复的执行单元

普通函数只有“调用”和“返回”。协程多了一个中间状态：

running -> yield/suspend -> suspended -> resume -> running

挂起时，运行时需要保存“以后从哪里继续”以及必要的局部状态。实现上通常有两类：

• 有栈协程：每个协程有自己的用户态栈，切换时保存/恢复栈指针和寄存器。
• 无栈协程：编译器把函数拆成状态机，局部变量变成状态对象的一部分。

Python generator 和 C++20 coroutine 更接近“无栈协程”的教学入口：每次 yield 或 co_yield 都是一个显式挂起点，调用者下次恢复时从挂起点之后继续执行。

重要的是：协程通常由用户态运行时调度，而不是由内核调度。它因此更轻：

OS 不需要为每个协程分配完整线程资源；
切换协程通常不需要陷入内核；
协程栈可以很小或由状态机替代。

但“轻”不等于“自动并行”。如果一个进程里只有一个 OS 线程在运行协程，那么这些协程只是并发推进，不会在多个 CPU 核上同时执行。

协程与用户态并发

把协程说成“用户态并发”方向是对的，但更精确的说法是：

协程是实现用户态并发的一种执行单元。

协程本身是“可暂停/可恢复的函数”；用户态并发是运行时把许多这样的函数组织起来，让它们在等待点交替推进。

调度方式通常是协作式的：

当前协程运行
-> 遇到 yield / await / 阻塞前的等待点
-> 主动交回控制权
-> 调度器选择另一个可运行协程

这和 OS 线程的抢占式调度不同。OS 可以在时钟中断、系统调用返回等位置强行切走线程；纯用户态协程如果不主动让出，其他协程就没有机会运行。

因此协程程序的关键不变量是：

所有可能长时间等待的操作，都必须变成“注册等待事件 + yield”。

否则，一个协程卡住，就可能把同一个 OS 线程上的所有协程一起卡住。

阻塞系统调用的陷阱

协程最大的陷阱是：操作系统看不到用户态运行时内部的一百万个协程，它只看到一个或少数几个 OS 线程。

如果某个协程直接调用阻塞系统调用：

read(fd, buf, n);   // 没有数据时阻塞
sleep(1);           // 线程睡眠

内核阻塞的是承载它的 OS 线程。结果是：

一个协程在内核里等待
-> 整个 OS 线程停止运行
-> 同线程上的其他协程也无法被调度

这就是讲义里的：

一个协程等待，1,000,000 个都等待。

另一个典型问题是同步原语和协作式调度组合不当。例如一个协程拿着锁之后 yield，调度器又恢复到需要同一把锁的协程，就可能形成进展性问题。协程运行时必须非常清楚哪些操作会让出控制权，哪些锁和资源在让出时仍被持有。

非阻塞 I/O 与 epoll

解决阻塞系统调用问题的基本方法是把 I/O 改成非阻塞：

open(..., O_NONBLOCK)

非阻塞 read 的语义是：

如果现在有数据：返回实际读到的字节数。
如果现在没数据：返回 -1，并设置 errno = EAGAIN / EWOULDBLOCK。

这给了协程运行时一个机会：

while (read(fd, buf, n) == -1 && errno == EAGAIN) {
    register_interest(fd, READABLE);
    yield();
}

但是只靠 O_NONBLOCK 还不够。运行时还需要知道“哪些 fd 现在可读/可写”。这就是 epoll 的位置。

epoll 的功能是：

让进程高效等待大量 fd 的就绪事件。

它不是让单次 read/write 更快，而是避免：

• 为每个连接创建一个 OS 线程。
• 反复线性扫描所有 fd。
• 在没有数据的 fd 上空转。

典型事件循环是：

1. 协程尝试 read/write。
2. 如果返回 EAGAIN，把 fd 和等待事件注册到 epoll。
3. 当前协程 yield。
4. 调度器运行其他可运行协程。
5. epoll_wait 返回就绪 fd。
6. 运行时恢复等待这些 fd 的协程。

可以把它压成：

协程负责表达“我要等什么”；
epoll 负责告诉运行时“哪些等待条件已经可能成立”；
调度器负责恢复对应协程。

这也是高并发网络服务器能用少量线程处理大量连接的基础。

eventfd、timerfd 与统一事件模型

讲义提到 eventfd、timerfd、io_uring，核心思想是把更多等待对象纳入统一事件循环。

timerfd 把定时器表示成 fd：

时间到了 -> fd 可读 -> epoll_wait 返回

eventfd 把用户态/线程间通知表示成 fd：

其他线程写 eventfd -> fd 可读 -> epoll_wait 返回

这样运行时就可以用同一个 epoll_wait 同时等待：

• socket 可读可写。
• pipe 可读。
• 定时器到期。
• 其他线程发来的唤醒事件。

这件事的抽象价值很大：

把“等待不同种类事件”统一成“等待 fd 就绪”。

io_uring 则更进一步，用提交队列和完成队列表达真正的异步 I/O，尤其适合传统 epoll 不擅长的磁盘 I/O 场景。

Goroutine 的工程化模型

goroutine 可以理解为 Go 对轻量执行流的工程化实现：

goroutine = Go runtime 调度的轻量任务

写：

go f()

不是直接创建一个 OS 线程，而是创建一个 goroutine，由 Go runtime 调度到某个 OS 线程上执行。

Go 的调度通常用 G-M-P 模型理解：

G = goroutine，用户态任务。
M = machine，实际 OS 线程。
P = processor，运行 Go 代码所需的调度资源和本地队列。

多个 G 会复用到少量 M 上运行，形成 M:N 调度。这样 goroutine 可以做到：

• 像线程一样写阻塞风格代码。
• 栈从很小开始，按需增长。
• 大量任务由 Go runtime 在用户态调度。
• 遇到网络 I/O 等等待时，runtime 配合 netpoller 暂停当前 goroutine，转去运行其他 goroutine。

所以 goroutine 的关键优势不是“语法短”，而是：

把线程式代码的可读性，和协程式调度的低成本结合起来。

它也不是凭空解决 CPU 并行。真正同时执行仍然依赖多个 OS 线程和多个 CPU 核；GOMAXPROCS 决定同一时刻可以并行执行 Go 代码的 P 的数量。

Channel 与通信式同步

讲义引用了 Effective Go 的一句话：

Do not communicate by sharing memory; instead, share memory by communicating.

信号量、条件变量、互斥锁能表达同步，但数据如何传递仍然靠程序员手工维护共享内存。如果忘记加锁、锁错对象或破坏不变量，就会回到 data race 和 atomicity violation。

Go channel 把同步和通信合在一起：

done <- id     // 发送：传递数据，也可能阻塞等待接收者
id := <-done   // 接收：取得数据，也可能阻塞等待发送者

这和 UNIX pipe 的思想接近：

生产者写入 channel / pipe
消费者读取 channel / pipe
数据流本身携带同步关系

课程里的 Mandelbrot-Go 例子可以这样理解：

多个 goroutine 分块计算像素行
-> 每个 worker 完成后向 done channel 发送完成事件
-> monitor 用 select 同时等待 done 和 timer
-> finish channel 通知主 goroutine 收尾

这里的 channel 不只是“队列”，也是 happens-before 边：发送完成事件先于接收方观察到完成。

异步编程的状态机视角

即使不展开 JavaScript，也需要保留异步编程的一般模型，因为它和协程是同一个问题的另一种表达。

async/await 的核心不是“自动多线程”，而是：

把一个顺序函数按 await 切成若干段，
每段在前一个等待事件完成后继续执行。

编译器或运行时大致会把：

do A
await event1
do B
await event2
do C

改写成状态机：

state 0: do A; register event1; suspend
state 1: do B; register event2; suspend
state 2: do C; finish

所以 await 和协程的 yield 在控制流意义上很像：都表示“保存当前状态，等以后恢复”。差别在于：

• 协程路线试图保留类似线程的执行流抽象。
• 异步路线更明确地把等待点暴露给语言和运行时。
• Future / Promise 把“未来完成的值”和依赖关系显式对象化。

这也是为什么很多语言的 async/await 看起来像同步代码，但底层并不是阻塞线程，而是在事件完成后继续执行后半段。

计算图视角下的统一理解

本讲仍然可以回到计算图：

节点 = 一段可以连续执行的代码
边   = 必须等待的事件、I/O 完成、channel 通信或 join 依赖

OS 线程模型的问题是：每个节点或每条等待链都可能占用一个重线程。协程和异步编程则尝试把等待中的节点从 OS 线程上摘下来。

可以这样对比：

OS thread:
  等待 I/O 时，线程阻塞在内核里。

Coroutine + epoll:
  等待 I/O 时，协程挂起，OS 线程继续跑其他协程。

Goroutine:
  程序员写阻塞风格代码，Go runtime 负责在等待时挂起 G，复用 M。

Async/await:
  程序员标出 await 点，编译器/运行时把函数拆成事件驱动状态机。

因此，本讲的主线不是“协程比线程高级”，而是：

真实 workload 里大量并发活动都在等待；
高性能运行时必须把等待成本从 OS 线程成本中解耦出来。

常见误解

协程是否就是用户态并发

可以粗略这么说，但更精确的是：

协程是用户态并发的执行单元；
用户态调度器把许多协程组织成并发程序。

只有一个协程时，它只是一个可暂停函数；有调度器和多个可运行协程时，才体现用户态并发。

协程是否天然并行

不是。协程本身只说明“可挂起/恢复”，不说明“能在多个 CPU 核上同时运行”。要并行，需要多个 OS 线程承载协程，或者像 Go runtime 那样把 goroutine 分配到多个 worker thread 上。

epoll 是否负责读写数据

不是。epoll 只告诉你 fd 是否就绪：

fd readable -> 现在调用 read 比较可能取得数据
fd writable -> 现在调用 write 比较可能写入缓冲区

真正的数据传输仍然由 read/write/recv/send 完成。就绪也不等于一定能读完整个请求；代码仍然要处理短读、短写、EOF、错误和重试。

async/await 是否就是多线程

不是。async/await 更像“把函数切成状态机”。它能让单线程在等待 I/O 时继续处理其他事件，但 CPU 密集代码如果一直运行，仍然会占住当前执行线程。

与系统性能的连接

协程和异步 I/O 服务的是典型 I/O 密集 workload：

大量连接
少量活跃
大量时间在等待网络、定时器或外部服务
每个请求的 CPU 工作不一定很重

这类 workload 如果用“一连接一线程”，会被栈空间、调度和 cache 扰动拖垮。如果用 epoll + coroutine 或 runtime netpoller，则可以让少量线程只在事件真正就绪时推进对应任务。

但 CPU 密集型 workload 不会因为换成协程自动变快。此时瓶颈是计算本身，需要回到第 18 讲的并行算法：

画计算图
选择任务粒度
减少同步边
改善局部性
用多线程 / SIMD / GPU 真正并行执行

对 AI infrastructure 来说，这个边界很重要：

• 请求接入、网络等待、排队、流式返回适合协程/异步 I/O。
• tokenizer、batching、调度器可以用 worker pool 和 channel/queue。
• GPU kernel 执行、矩阵计算、推理算子优化属于并行计算和硬件局部性问题。
• serving 系统常常把两类模型组合起来：上层协程处理大量请求，下层线程池/GPU worker 执行重计算。

本节知识点总结

1. OS 线程不是免费的：栈、内核对象、调度、上下文切换和缓存扰动都会成为成本。
2. 第 19 讲的核心问题是：如何让大量等待型并发任务不再各占一个重线程。
3. 协程是可挂起/可恢复的执行单元，通常由用户态运行时调度。
4. 协程实现可以有栈，也可以由编译器改写成无栈状态机。
5. 协程轻量不等于自动并行；并行仍然依赖多个 OS 线程和多个 CPU 核。
6. 阻塞系统调用会阻塞承载协程的 OS 线程，因此协程运行时必须配合非阻塞 I/O。
7. `O_NONBLOCK` 让无数据的 `read` 返回 `EAGAIN`，从而允许协程注册等待事件并 `yield`。
8. `epoll` 负责高效等待大量 fd 的就绪事件，是协程网络运行时的重要基础。
9. `eventfd`、`timerfd` 把通知和定时器也纳入 fd 事件模型，方便统一调度。
10. Goroutine 是 Go runtime 调度的轻量任务，通过 `G-M-P` 模型把大量 G 复用到 OS 线程上。
11. Channel 把同步和通信合在一起，发送/接收既传递数据，也建立执行顺序。
12. `async/await` 的本质是把函数按等待点拆成状态机，不是自动创建线程。
13. 协程/异步适合 I/O 密集并发；CPU 密集加速仍要靠并行算法、线程、SIMD 或 GPU。

同步问题的基本语义

互斥解决的是“同一时刻谁能访问共享状态”，同步解决的是“某个事件必须发生在另一个事件之前”。在多线程程序中，很多问题并不是单纯的数据竞争，而是某个线程必须等待共享状态满足某个条件后才能继续。

同步问题可以统一写成：

while (!sync_condition()) {
    wait();
}
proceed();

sync_condition() 是共享状态上的谓词，例如“所有子线程已经结束”“缓冲区非空”“前驱节点全部完成”。条件变量的作用就是把这种等待从忙等变成阻塞等待，并在状态可能改变时唤醒等待者。

条件变量的状态条件模型

条件变量本身不保存业务状态，也不表示条件已经成立。真正的条件必须由共享变量记录，并由互斥锁保护。

典型组成是：

• 共享状态：标志位、计数器、队列长度、剩余依赖数等。
• 互斥锁：保护共享状态的检查与修改。
• 条件变量：让等待条件的线程睡眠，并在条件可能成立时被唤醒。

因此条件变量不是“消息队列”，也不是“带记忆的 signal”。如果没有线程正在等待，一次 cond_signal 或 cond_broadcast 通常不会被保存。正确性来自“共享状态 + mutex + while 检查”的组合，而不是来自通知本身。

cond_wait 的原子释放与等待

cond_wait(&cv, &lk) 的核心语义是：调用时线程必须已经持有 lk；进入等待时，库会原子地释放 lk 并把当前线程加入 cv 的等待队列；被唤醒后，线程会先重新获得 lk，再从 cond_wait 返回。

这个原子性用于避免漏唤醒：

错误模型：
线程 A 检查 condition == false
线程 A 手动 unlock，准备 sleep
线程 B 修改 condition == true，并 signal
线程 A 还没有进入等待队列，通知丢失
线程 A 随后 sleep，可能永久阻塞

如果 cond_wait 不释放锁，修改条件的线程又无法拿到锁推进状态，等待者会拿着锁睡眠，系统直接失去进展。因此 cond_wait 必须同时满足两点：等待者睡眠时不持有锁；释放锁和进入等待队列之间没有可见空窗。

条件变量的标准使用模板

等待者模板：

mutex_lock(&lk);
while (!cond) {
    cond_wait(&cv, &lk);
}
// 此时 cond 成立，并且当前线程持有 lk
do_work_under_condition();
mutex_unlock(&lk);
cond_broadcast(&cv);

修改者模板：

mutex_lock(&lk);
update_shared_state();
mutex_unlock(&lk);
cond_broadcast(&cv);

必须使用 while 而不是 if。在 Mesa 语义下，唤醒只表示“条件可能已经改变”，不保证条件在当前线程重新获得锁时仍然成立。可能出现假唤醒、多个线程争抢同一份资源、或者条件被其他线程再次改回去。

唤醒与重新竞争互斥锁

cond_broadcast(&cv) 唤醒一组等待线程时，这些线程不会同时从 cond_wait 返回。它们只是从条件变量等待队列进入可运行状态，并开始竞争同一把互斥锁。

过程可以理解为：

T0 持有 lk
T0 修改共享状态
T0 cond_broadcast(cv)
等待在 cv 上的线程被唤醒，但仍不能从 cond_wait 返回
T0 mutex_unlock(lk)
被唤醒的线程竞争 lk
只有一个线程获得 lk，并重新检查 while 条件
条件不成立的线程再次 cond_wait

因此 broadcast + while 是鲁棒组合：broadcast 负责通知所有可能受影响的线程，while 负责筛掉当前条件并不满足的线程。

broadcast 与解锁顺序

常见模板选择先 cond_broadcast 再 mutex_unlock：

update_shared_state();
cond_broadcast(&cv);
mutex_unlock(&lk);

这样可以把“共享状态已经修改”和“等待者可以重新检查”绑定在同一个临界区中。被唤醒的线程即使已经可运行，也必须等当前线程释放锁后才能从 cond_wait 返回，因此不会在状态更新尚未完成时抢跑。

严格说，部分实现和部分场景允许在解锁后通知，但这种写法更难证明。课程中的稳妥规则是：修改了可能影响同步条件的共享状态，就在持锁状态下广播，然后释放锁。

左右括号模型的不变量

第 15 讲把生产者-消费者问题简化成左右括号打印：

void T_producer() { printf("("); }
void T_consumer() { printf(")"); }

令 depth 表示当前未被右括号匹配的左括号数量，令 n 表示最大允许嵌套深度。系统需要维护的不变量是：

0 <= depth <= n

对应的同步条件是：

打印 "(" 的条件：depth < n
打印 ")" 的条件：depth > 0

左括号线程生产一份未匹配的左括号，使 depth++；右括号线程消费一份未匹配的左括号，使 depth--。因此任何前缀中右括号数量都不能超过左括号数量，并且嵌套深度不能超过缓冲区容量 n。

左括号生产者的条件变量实现

左括号线程的代码是生产者逻辑：

void T_producer() {
    mutex_lock(&lk);
    while (!(depth < n)) {
        cond_wait(&cv, &lk);
    }

    assert(depth < n);
    depth++;
    printf("(");

    cond_broadcast(&cv);
    mutex_unlock(&lk);
}

depth++ 和 printf("(") 放在同一个临界区内，是因为输出序列本身也是共享结果。若先修改 depth 再让其他线程插入打印，输出字符与深度状态就可能不一致。

右括号线程是对称的消费者逻辑：

void T_consumer() {
    mutex_lock(&lk);
    while (!(depth > 0)) {
        cond_wait(&cv, &lk);
    }

    assert(depth > 0);
    depth--;
    printf(")");

    cond_broadcast(&cv);
    mutex_unlock(&lk);
}

当一个左括号线程把 depth 从 0 改为 1 并广播后，多个右括号线程可能同时被唤醒，但只有一个线程能先获得锁。第一个右括号线程可能把 depth 重新减为 0，其余右括号线程随后重新检查 depth > 0，发现条件不成立后继续睡眠。

signal 与 broadcast 的选择边界

cond_signal 只唤醒一个等待者，开销较小，但要求程序员能够证明被唤醒的线程一定有机会继续执行。在左右括号例子中，同一个条件变量上可能同时等待 producer 和 consumer。若 producer 释放出机会后唤醒了另一个 producer，而该 producer 的条件并不成立，就可能造成无效唤醒甚至活性问题。

cond_broadcast 会唤醒所有等待者，让每个线程重新检查自己的条件。它可能带来额外上下文切换和抢锁开销，但配合 while 更容易保证正确性。课程中的默认策略是：只要某次共享状态修改可能使其他线程的同步条件成立，就使用 broadcast。

生产者-消费者模型的同步结构

经典生产者-消费者模型维护一个容量为 N 的有界缓冲区。共享状态可以抽象为当前元素个数 cnt，不变量是：

0 <= cnt <= N

对应的两个等待条件是：

producer 可继续：cnt < N
consumer 可继续：cnt > 0

实际代码中通常拆成两个条件变量：

void produce(Object x) {
    mutex_lock(&m);
    while (cnt == N) {
        cond_wait(&not_full, &m);
    }
    put(x);
    cnt++;
    cond_broadcast(&not_empty);
    mutex_unlock(&m);
}

Object consume() {
    mutex_lock(&m);
    while (cnt == 0) {
        cond_wait(&not_empty, &m);
    }
    Object x = take();
    cnt--;
    cond_broadcast(&not_full);
    mutex_unlock(&m);
    return x;
}

两个不同等待条件对应两个条件变量，是为了减少误唤醒：等待“非满”的 producer 和等待“非空”的 consumer 不应混在同一个等待集合中。

同步正确性与并行性能边界

条件变量保证的是同步正确性，不自动带来并行加速。是否退化成串行，取决于临界区占总工作量的比例。

左右括号例子几乎会退化成串行，因为主要工作就是更新 depth 并打印一个字符，而这两件事都必须在锁内完成。它是同步语义教学例子，不是高吞吐并行程序。

真正适合生产者-消费者优化的场景通常具有“短交接、长计算”的结构：

producer:
    x = make_object();      // 锁外并行
    lock();
    enqueue(x);             // 锁内短临界区
    broadcast();
    unlock();

consumer:
    lock();
    x = dequeue();          // 锁内短临界区
    broadcast();
    unlock();
    process(x);             // 锁外并行

此时锁只串行化共享队列的 push/pop，真正耗时的生产、处理、I/O 或计算在锁外执行。并行度来自锁外工作与流水线重叠，而不是来自条件变量本身。

任务流水线的生产者-消费者化

一个模型服务流水线可以被拆成多个生产者-消费者阶段：

请求线程 -> request_queue -> tokenizer workers
tokenizer workers -> token_queue -> batcher
batcher -> batch_queue -> GPU worker
GPU worker -> result_queue -> response workers

每个队列的 push/pop 由短临界区保护，每个阶段的主体工作在锁外完成。这样 GPU 推理、CPU 分词、响应发送可以重叠运行。队列和条件变量只负责阶段之间的资源交接与等待唤醒。

万能同步方法的计算图解释

生产者-消费者模型可以推广到任意同步条件。关键步骤是：

识别必须等待的 sync condition
用共享状态记录事件或资源是否可用
后执行者在 while (!condition) 中等待
先执行者修改共享状态并 broadcast

在 DAG 计算图中，边 u -> v 表示 v 必须等待 u 完成。每个节点 v 可以维护 n_pending_deps：

mutex_lock(&v->m);
while (v->n_pending_deps > 0) {
    cond_wait(&v->ready_cv, &v->m);
}
mutex_unlock(&v->m);
run(v);

当某个前驱完成后，减少后继节点的剩余依赖数：

mutex_lock(&succ->m);
succ->n_pending_deps--;
if (succ->n_pending_deps == 0) {
    cond_broadcast(&succ->ready_cv);
}
mutex_unlock(&succ->m);

Makefile 的 make -j、动态规划依赖图、神经网络计算图和工作流调度都可以用这个视角理解：每个节点等待前驱生产完成事件，前驱完成后唤醒后继重新检查可执行条件。

条件变量使用原则

• 条件变量表达“何时可以继续”，互斥锁保护“谁能访问共享状态”。
• 条件变量不保存业务状态，条件必须由共享变量表示。
• cond_wait 必须在持锁时调用，并原子释放锁与进入等待。
• 被唤醒后必须重新获得互斥锁，才能从 cond_wait 返回。
• 等待条件必须写成 while (!cond)，不能写成 if。
• 修改可能影响同步条件的共享状态后，默认使用 cond_broadcast。
• 临界区只应覆盖共享状态交接；主要计算应尽量放在锁外。

线程的基本执行模型

从操作系统视角看，线程可以先抓成一句话：

thread = 独立栈 + 独立寄存器上下文 + 共享地址空间

和进程相比，线程不再复制整个地址空间，而是在同一个进程里共享：

• 代码段
• 全局变量 / 静态存储区
• 堆
• 打开的文件描述符等进程级资源

每个线程自己单独拥有：

• PC/RIP
• 通用寄存器
• 栈

所以“多线程程序”的本质不是魔法，而是：

同一份共享内存上，同时挂了多个“CPU 状态机”

这也是讲义里最核心的模型：每个线程独立栈，共享全局。

线程作为并发抽象的动机

父子进程之间通信和切换代价更大，因此很多“同一任务里的并发活动”更适合放到同一个地址空间里做。线程带来的直接好处是：

• 共享数据便宜，不必每次 IPC
• 创建 / 销毁成本通常低于新进程
• 一个进程内部可以更自然地表达并发结构

但代价也很直接：共享内存把顺序程序的确定性打碎了。

并发与并行的概念区分

• 并发：逻辑上同时推进。单核靠来回切换也能并发。
• 并行：物理上同时执行。至少需要多个核。

关系是：

parallelism => concurrency
concurrency =/=> parallelism

讨论 bug 时，重点通常不是“有没有两个核”，而是“多个执行流是否可以以非确定顺序访问共享状态”。

线程栈的结构与性质

栈的功能与存储内容

线程栈主要放：

• 调用帧
• 返回地址
• 保存的寄存器
• 局部变量
• 部分临时对象

它不是语言层面的“神秘盒子”，本质上就是线程私有的一段地址空间。

线程栈大小的来源与决定因素

C 语言标准并不规定线程栈大小；它由 OS、线程库和创建参数共同决定。

在本课讲义和常见 Linux pthread 环境里，实验常见结果是：

每个新线程默认栈大约 8 MB

这也是为什么讲义里说：10000 个线程大约就会吃掉 80 GB 量级的虚拟地址空间。

要注意：主线程栈和 pthread_create 创建出来的线程栈不一定遵守同一套默认规则；课程里的 8 MB 更接近“新建线程的常见默认值”。

更准确地说，线程栈大小由这些因素决定：

• OS / ABI 默认策略
• 线程库默认值，如 pthread 默认栈大小
• 进程资源限制，如 RLIMIT_STACK
• 显式配置，如 pthread_attr_setstacksize
• guard page、对齐、TLS 等运行时细节

线程栈的私有性与可访问性

“独立”指的是：

• 正常调用约定下，每个线程主要在自己的栈上活动
• 栈帧生命周期和寄存器上下文由该线程自己推进

但它们仍然都在同一个进程虚拟地址空间里。
所以如果你把一个线程局部变量的地址传给另一个线程，另一个线程仍然可能读写它。换句话说：

线程栈是按使用习惯划分的私有区域，不是硬件隔离的独立地址空间。

pthread 与线程模型的程序接口

课程里用了 spawn/join 的极简 API，本质上就是对 pthread_create/pthread_join 的做减法封装。

常见 C 接口可以直接记成：

pthread_create
pthread_join
pthread_mutex_lock / unlock
pthread_cond_wait / signal / broadcast

调试多线程时，gdb 很重要的命令是：

info threads
thread <id>
set scheduler-locking on

其中 set scheduler-locking on 的含义是：单步时尽量只让当前线程前进，避免别的线程在你 step 的空档里继续乱跑。

并发执行中的非确定性

单线程程序大致可以看成：

state_{n+1} = f(state_n)

给定初始状态，程序行为基本是确定的。

多线程以后，不再只是“执行下一条语句”，而是变成：

1. 选一个线程
2. 让它执行一步
3. 再选下一个线程

这个“选哪个线程”的动作通常不受你控制，所以程序从“函数”变成了“带分叉的状态图”。

这就是并发最根上的困难：不是代码更长了，而是执行路径指数爆炸了。

读改写操作的竞态条件

sum++ 在机器上通常不是一条不可分割的神谕，而更接近：

load sum
add 1
store sum

两个线程如果都这么做，就可能出现：

1. A 读到 sum = 0
2. B 也读到 sum = 0
3. A 写回 1
4. B 再写回 1

最后只加了一次。

所以 sum++ 的问题本质不是“加法错了”，而是：

一个本来你以为是单步的操作，被撕成了多个可交错的内存动作。

这和转账里的 check-then-act 是同一类 bug：

if (balance >= amount) balance -= amount;

两个线程可能都通过检查，然后都扣款。

trace recovery 问题及其复杂性

讲义提到的 trace recovery，核心是：

已知每个线程各自做了哪些局部动作，是否存在某种合法交错，使全局执行满足目标结果？

比如 k 个线程各做若干次 sum++，问最终 sum 的最小可能值，本质上就在问：

• 能否安排一条全局执行轨迹
• 让大量中间结果被后来的写覆盖
• 最后只留下极少数“有效写入”

它难，不是因为表达式复杂，而是因为：

• 每个线程内部顺序必须保持
• 不同线程之间可以交错
• 要搜索的合法全局轨迹数目非常大

所以这是一个典型的“局部顺序 + 全局约束 + 搜索交错”的问题。讲义里把它归到 NP-complete，直觉上就是：

你需要在指数级候选 interleaving 里，找一个满足目标条件的执行轨迹。

你可以把它理解成：并发程序的很多“结果可不可达”问题，本质上都像在做组合搜索。

编译器优化对并发语义的影响

单线程优化默认依赖一个强假设：

没有别的执行流在偷偷改我的内存

因此编译器会放心做这些事：

• 把多个 x++ 合并成 x += k
• 把循环不变量提到循环外
• 把某个内存值缓存进寄存器，不再重读

这在单线程里完全合理，但在共享内存并发里会炸。

最经典的是：

while (!flag) { }

如果 flag 不是原子同步对象，编译器可能把它理解成：

flag 在循环体里没被改过，所以读一次就够了

于是优化成近似死循环。

这也是为什么：

• volatile 不是通用并发同步方案
• 裸共享变量上的 busy wait 是危险的

处理器执行与内存可见性的偏离

即使编译器不乱动，硬件也不会老老实实按你脑中的“共享内存教科书图”执行。

现代 CPU 为了性能，至少会做两类事：

• 指令乱序执行
• store buffer + cache coherence 延迟传播

所以你写：

x = 1;
r = y;

另一边写：

y = 1;
r = x;

按顺序一致性直觉，你会以为不可能两个读都看到 0。 但真实硬件上 (0, 0) 是可以出现的，因为：

• 写先进入各自核心的 store buffer
• 本核后续 load 可能先执行
• 别的核心还没来得及看到这个写

内存系统中的最终一致性

这里的“最终一致性”不是数据库课里那套 marketing 词，而是一个很弱的硬件直觉：

如果某个地址不再被继续写入，那么过一段时间后，各核心最终会收敛到同一个值。

它只保证“最终会一致”，不保证：

• 刚写完别人立刻看到
• 多个地址按程序顺序一起对外可见
• 某个复合不变量一直成立

所以它很弱，只能说明“副本不会永远分叉”，完全不足以支撑并发程序正确性。

MESI 协议的保证范围

根据 MESI 一类缓存一致性协议，很多人会误以为：

某核心一写，别的核心立刻就能观察到

这不对。

对外可见性的传播可能在不同核、不同 cache line 上表现出不同的生效时机，所以当前的缓存状态不一定被及时更新，进而可能导致缓存信息不同

MESI 主要保证的是 cache coherence，也就是：

• 对同一个 cache line，不会长期存在多个彼此矛盾的可写副本
• 其他核心以后再读这个地址时，会通过一致性协议收敛到合法的新值

但它不保证：

• 某次写一完成，所有核心立刻同步完成更新
• 已经在路上的读操作必须马上改看到新值
• 多个地址的写入对外具有统一顺序

所以更准确的说法是：

MESI 解决“同一地址的副本如何收敛”，不解决“多个地址的可见性顺序如何推理”。

后者属于 memory consistency / memory model 的范围。

跨地址可见性与顺序约束问题

看这个最经典的模式：

data = 42;
flag = 1;

另一线程：

if (flag == 1) {
  assert(data == 42);
}

即使 flag 和 data 各自都受 cache coherence 保护，第二个线程仍然可能先看到 flag == 1，却还没看到 data == 42。

原因是：

• coherence 只管单个地址
• flag 和 data 是两个不同位置
• 它们对别的核心可见的先后顺序未必和程序顺序一致

所以并发正确性需要的不是“每个地址最终会一致”，而是：

某些写必须在语义上先于某些读可见

这就需要：

• mutex
• atomic
• acquire / release
• fence

来建立 happens-before。

线程安全与原子性的区别

这两个词很容易混：

• thread-safe：多个线程一起调用，不会把库内部状态搞坏
• atomic：这次操作对外表现得像不可分割的单步

例如：

• printf 内部通常加锁，所以是 thread-safe
• 但它并不意味着整个输出过程对你程序里的其他逻辑是原子的
• memcpy 即使是 thread-safe，也不代表两个线程同时往同一目标拷贝会得到“某一个完整版本”

所以以后看到“线程安全”，先问一句：

它保证的是内部不炸，还是保证对共享状态的操作具备我想要的原子性？

对顺序程序直觉的修正

不是放弃并发编程，而是放弃这些顺序程序直觉：

• 相邻语句会按写的顺序执行
• 一个表达式就是一步
• 共享变量的最新值别人立刻能看到
• 测了很多次没出错就说明程序正确

多线程里更靠谱的心智模型是：

线程 = 多个局部顺序流
共享内存 = 可被并发读写的全局状态
正确性 = 在所有允许的 interleaving + 编译器优化 + CPU 重排下都成立

所以课程后面引入 mutex、condition variable、semaphore、atomic，不是为了“加点 API”，而是为了把并发重新约束回一个可以证明的模型里。

本节知识点总结

1. 线程 = 独立栈 + 独立寄存器 + 共享地址空间。
2. 线程栈通常是固定配额；Linux/pthread 常见默认约 8 MB，但本质由 OS/线程库/配置决定。
3. 并发的根问题不是语法，而是“下一步谁执行”带来的非确定性。
4. sum++ / check-then-act 出错，是因为一个你以为的“单步”被撕成了可交错的 load/store。
5. trace recovery 关注“是否存在某种合法执行轨迹”，其搜索空间巨大，所以结果可达性会很难。
6. 编译器会重写代码，CPU 会乱序和延迟传播写入，shared memory 并不是“所有核立刻共享同一个值”。
7. eventual consistency 只保证最终收敛，不保证立即可见，更不保证跨地址顺序。
8. MESI 解决的是单地址 coherence，不是完整并发语义。
9. 并发正确性最终要靠 mutex / atomic / happens-before，而不是靠直觉。

互斥问题的基本模型

线程共享地址空间后，问题不再是“有没有两个核”，而是“多个执行流会不会以不受控制的顺序访问同一份共享状态”。如果会，那么像 sum++、check-then-act 这样的操作就可能被撕成可交错的 load/add/store，从而破坏不变量。

这时就需要把一段“不能被并发打断”的代码圈出来。这段代码叫 critical section。它是一个语义边界，表示：

• 这一段访问了共享状态；
• 若多个线程同时执行，会破坏正确性；
• 因而需要某种机制保证它对外表现得像“一个一个来”。

所以三者不要混：

• critical section：问题定义，指出哪段代码必须受保护；
• mutex：最常见的实现机制，用 lock/unlock 把临界区串行化；
• transactional memory：另一种更高层机制，把一段代码当作事务执行，冲突时回滚重试。

也就是说，临界区不是锁；锁只是实现临界区的一种办法。课堂主线关注的是 mutex，因为它最直接、最工程化。

互斥锁的语义保证

讲义里最重要的直觉是：lock/unlock 相当于对一段代码做了一次局部的 stop the world。

lock();
// critical section
unlock();

只要程序员正确使用同一把锁保护相关共享状态，就可以把这段代码近似看成：

• 进入前，别的线程不能同时执行同一把锁保护的临界区；
• 离开后，临界区里的写入会对下一个拿到锁的人可见。

这也是为什么 mutex 不只是“门口放一把钥匙”，它还自带内存顺序语义：

• lock 近似 acquire：拿到锁后，能看到上一个 unlock 之前写入的内容；
• unlock 近似 release：离开临界区前，把这段代码的写入对后继持锁者发布出去。

所以互斥锁解决的不只是“同时只能进一个人”，还顺手建立了 happens-before。这正是它比“自己写两个共享变量轮询”可靠得多的原因。

互斥锁的使用原则与粒度策略

锁最常见的 bug 不是算法高深，而是保护边界画错了。最重要的原则有三条：

• 保护同一组共享不变量的代码，必须用同一把锁；
• lock 和 unlock 必须成对，且异常路径也不能漏；
• 临界区里尽量不要做 I/O、睡眠、阻塞等待等长耗时操作。

一个经典错误是“访问同一个共享变量，却用了两把不同的锁”：

lock_t L, I;

void T1() { lock(&L); sum++; unlock(&L); }
void T2() { lock(&I); sum++; unlock(&I); } // BUG

看起来都“加锁了”，其实没有互斥，因为两段代码没有被同一把锁串行化。

关于锁粒度，课程给出的工程建议非常朴素：从一把大锁开始。

• 一把大锁最不容易错；
• 先把程序写对，再做压力测试和 profile；
• 只有证明锁竞争真是瓶颈，才拆成细粒度锁。

Linux 早期的 Big Kernel Lock 就是这么来的：先让系统在多处理器上“能工作”，再花很多年沿着真实瓶颈慢慢拆。对学习和工程都一样，先正确，再优化。

互斥与并行性的关系

乍看上去，互斥就是强行串行化，似乎和并行完全对立；但真正的判断标准是“被串行化的部分到底占多大”。

从固定工作量看，Amdahl's Law 说：

$ S(N) = \frac{1}{s + \frac{1-s}{N}} $

其中 s 是不可并行部分。它强调的是瓶颈：只要串行部分不为 0，加速比就有上限。锁把临界区串行化，等于增大了 s，所以临界区越大，并行扩展性越差。

从可扩展工作量看，Gustafson's Law 则更乐观：如果总运行时间大致固定，而问题规模可以随处理器数增加，那么绝大多数并行部分都能扩张，多核仍然有意义。

所以二者并不矛盾，只是回答不同问题：

• Amdahl：固定任务规模下，加核的上限有多高；
• Gustafson：在相近时间预算下，机器变强后能把问题做多大。

对锁的启发是：不要空想“完全无锁的完美并行”，而是要问“真正被锁住的关键路径有多长，能否足够局部化”。

互斥实现的历史路径：Peterson 到原子指令

讲义专门走了一遍历史路径：先尝试纯软件互斥，再承认这条路在现代机器上不对劲，最后让硬件提供原子指令。

Peterson 协议是两线程互斥的经典算法：

int flag[2] = {0, 0};
int turn;

void lock(int self) {
    flag[self] = 1;
    turn = 1 - self;
    while (flag[1 - self] && turn == 1 - self) {
        ;
    }
}

void unlock(int self) {
    flag[self] = 0;
}

它在顺序一致性假设下是正确的：两个线程都想进时，用 turn 打破平局；如果只有一个线程想进，它可以直接进入。

但它有两个致命边界：

• 只直接适用于 2 个线程；推广到 n 线程虽有 Filter lock、Bakery algorithm 一类方案，但代价高，工程上几乎不用；
• 它依赖“普通 load/store 原子且按程序顺序生效”的强假设，而现代编译器和 CPU 的重排会破坏这个前提。

所以 Peterson 的价值主要是：

• 它说明了互斥问题本身可以被精确定义和证明；
• 它说明“测试很多次没出错”不等于程序正确；
• 它也说明在现代机器上，直接靠普通共享变量硬写锁并不是对的努力方向。

更现实的解法是让硬件直接给出原子读改写指令，例如 LOCK、LL/SC、CAS、fetch_add。这样“不可分割”不再靠协议模拟，而由 ISA 保证。

自旋锁的实现机制与适用边界

有了硬件原子指令之后，最直接的锁实现就是自旋锁：

typedef int spinlock_t;
#define LOCKED 1
#define UNLOCKED 0

void spin_lock(spinlock_t *lock) {
    while (__atomic_exchange_n(lock, LOCKED, __ATOMIC_ACQUIRE) == LOCKED) {
        ;
    }
}

void spin_unlock(spinlock_t *lock) {
    __atomic_store_n(lock, UNLOCKED, __ATOMIC_RELEASE);
}

它的模型非常简单：

• 抢锁成功就继续；
• 抢不到就原地 busy wait。

spinlock 解决的是互斥，但它的等待方式非常激进：拿不到锁时不睡觉，只烧 CPU。它因此只适合很窄的场景：

• 临界区极短；
• 持锁线程几乎不会被抢占；
• 等待时间预计远小于一次睡眠/唤醒/调度切换的成本。

它的两大缺陷也正来自这里：

• 一个线程持锁时，其他核可能“一核有难，八核围观”，全部空转；
• 更糟的是持锁线程若被调度出去，等待者还会继续白烧 CPU，直到它重新被调回来。

这也是为什么线程数超过 CPU 核数后，spinlock 往往性能断崖式下跌。

内核参与的阻塞式加锁机制

只靠 spinlock，线程拿不到锁时唯一能做的就是一直试。但如果想做到“拿不到锁就睡，锁可用时再醒”，线程自己做不到，必须让操作系统参与。

这就是“把锁的实现放入操作系统中”的含义：等待锁不再只是用户态里的循环，而变成：

• 线程发现锁被占用；
• 进入内核，告诉调度器“我在等这把锁”；
• 内核把它挂到等待队列，标记为休眠/阻塞；
• 解锁时内核再唤醒等待者。

最朴素的伪代码是：

void lock(int *m) {
    while (syscall(SYS_mutex_acquire, m)) {
        ; // 内核内部会把当前线程睡眠
    }
}

void unlock(int *m) {
    syscall(SYS_mutex_release, m);
}

这样做的好处是：

• 等待者不再空转；
• 调度器知道谁在等谁；
• 可以用睡眠-唤醒代替忙等。

代价是：

• 每次 lock/unlock 可能都要进内核；
• 系统调用和上下文切换都有开销。

所以“全靠用户态自旋”和“每次都进内核”都太极端。现代系统采用的是折中路线。

Futex 的混合实现模型

futex 的全称就是 fast userspace mutex。它不是“另一种高层语义上的锁”，而是一种把用户态原子操作和内核睡眠/唤醒拼起来的底层机制。

核心思想是两条路径：

• fast path：没人竞争时，直接在用户态用原子指令拿锁和放锁，不进内核；
• slow path：抢不到锁时，调用 futex(FUTEX_WAIT, ...) 让内核把线程挂起；释放锁时若发现有等待者，再 futex(FUTEX_WAKE, ...) 唤醒它们。

因此四个概念必须分清：

• spinlock：互斥语义，等待方式是忙等；
• mutex：互斥语义，等待方式通常是阻塞；
• futex：底层睡眠/唤醒机制，用来高效实现前者中的阻塞路径；
• pthread_mutex_t：对程序员暴露的高层 mutex API，glibc 背后常常靠 futex 实现。

所以“mutex 和 futex 有什么区别”时，最准确的答案是：

• mutex 是同步语义；
• futex 是 Linux 里常见的实现机制。

讲义里的 benchmark 结论也很直观：多数场景下性能大致是 atomic > mutex > spin > trap。其中 trap 指每次都强行进内核的朴素方案，它慢正说明了为什么 futex 一定要保留用户态快路径。

相关概念辨析

• critical section：一段必须看起来原子执行的代码区域，是问题定义；
• mutex：保证临界区互斥进入的高层原语；
• transactional memory：另一种实现临界区原子性的机制，冲突时回滚；
• Peterson：两线程、顺序一致性假设下的纯软件互斥协议，教学价值大于工程价值；
• spinlock：基于原子交换的忙等锁，适合极短临界区；
• syscall-based lock：拿不到锁就交给内核阻塞，正确但慢；
• futex：用户态快路径 + 内核慢路径的混合机制，是现代 pthread_mutex_t 的常见底层。

本节小结

1. critical section 是“哪段代码必须受保护”，mutex 是“怎么保护”的机制。
2. lock/unlock 不只是串行化，还建立 acquire/release 语义和 happens-before。
3. 锁的第一原则是“同一组共享不变量用同一把锁”，工程上先一把大锁，再按瓶颈细化。
4. Amdahl 讲固定规模下的串行瓶颈上限，Gustafson 讲固定时间下的规模扩展。
5. Peterson 协议能帮助理解互斥证明，但只直接适用于 2 线程，且依赖现代机器并不满足的强假设。
6. spinlock 用忙等换低延迟；一旦等待时间长或线程数超过核数，就会浪费 CPU 甚至崩溃。
7. 把锁“放进操作系统”就是把等待锁这件事交给调度器，用睡眠/唤醒替代空转。
8. futex 不是 mutex 的同义词，而是 Linux 中常用的底层实现机制：无争抢走用户态，争抢走内核。

第 18 讲的核心问题不是“并发程序如何写对”，而是“已经写对以后，如何让它随 CPU、线程数甚至机器数增长而加速”。互斥锁、条件变量、信号量能把共享状态的不变量保护起来，但如果所有操作都被压成一个全序，程序就获得了正确性，却失去了 scalability。

本讲可以压缩成一个统一模型：

把共享热点移出高频路径，把同步边压到计算图边界。

并行算法关注如何把计算拆成大块本地任务；并行数据结构关注如何把全局共享状态拆成局部状态、分片状态或近似状态。二者本质相同：减少必须被 release-acquire 串行化的事件。

从互斥正确性到可扩展性瓶颈

并发编程中最常见的操作仍然是 sum++ 这一类极短临界区：

void T_sum() {
    mutex_lock(&lk);
    sum++;
    mutex_unlock(&lk);
}

现实系统中的很多操作都具有同样形态：

buf[len++] = elem;
mapping[key] = value;
counter++;
queue.push(task);

互斥锁给出的保证很强：

unlock(lk) release
lock(lk)   acquire

只要所有线程都用同一把锁保护同一组共享状态，每次临界区就可以被理解为某个全局顺序中的一个原子步骤。这解决了 data race、lost update 和不变量破坏问题。

但它也带来硬瓶颈：如果每次 sum++ 都必须进入同一把锁，那么无论有 1 个核还是 128 个核，同时能推进这个操作的线程仍然只有一个。临界区越短，锁本身的同步、缓存一致性和调度成本占比越高；线程越多，竞争越重，扩展性越差。

因此，本讲讨论的不是“是否需要同步”，而是：

哪些同步是语义上必要的？
哪些同步只是实现方式造成的热点？

Scale Up 与 Scale Out

Scale up 是单机内增加 CPU、核心、硬件线程，让同一个程序获得更高吞吐。Scale out 是增加机器，让集群整体吞吐增长。

二者的共同条件是：问题必须能分解为大量主要本地执行、少量边界通信的任务。典型结构是：

mutex_lock(&lk);
job = get();
mutex_unlock(&lk);

job->run();   // 主要是线程本地计算
job->done();  // 释放后继任务

只要 job->run() 的时间远大于获取任务、提交结果、唤醒后继任务的同步时间，系统就有机会 scale。如果任务本身只有几条指令，同步就会吞掉所有并行收益。

这个模型和第 15/16 讲的同步原语直接相连：

• 条件变量适合表达“所有 predecessor 完成后才能继续”。
• 信号量可以把 predecessor 的完成事件抽象成若干把 key。
• 互斥锁保护 ready queue、引用计数、完成状态等共享元数据。
• 真正的并行工作应该尽量位于锁外。

计算图模型

并行算法的基本抽象是计算图：

节点 = 一段本地计算
边   = 数据依赖 / 同步约束

如果两个节点之间没有路径依赖，它们就可以并行执行。算法设计的关键不是机械地“开很多线程”，而是设计一张具有足够宽度、足够粗粒度、关键路径足够短的计算图。

评价一张并行计算图时，至少要看三个量：

work  = 总计算量
span  = 关键路径长度
grain = 单个任务的计算粒度

理论并行度近似受 work / span 限制；实际并行度还受同步、调度、缓存和通信开销限制。一个看似有很多节点的图，如果每个节点都很小，调度和同步会成为主要开销。

粒度选择与动态规划反例

以 LCS、编辑距离、矩阵 DP 为例，单个格子的转移通常依赖左、上、左上：

DP[i][j] = f(DP[i - 1][j], DP[i][j - 1], DP[i - 1][j - 1]);

最天真的并行化是把每个格子当成一个任务。这样会得到大量节点，但每个节点只做极少数加法、比较或赋值，却需要等待多个 predecessor、通知多个 successor。同步成本会远大于计算成本。

更合理的做法是按对角线或按块划分：

1. 同一条反对角线上的格子互不依赖，可以并行。
2. 块内顺序计算，块间按依赖同步。
3. 块越大，同步越少，但可并行宽度下降。
4. 块越小，可并行宽度上升，但同步和调度成本增加。

这就是 granularity tuning：把任务切到“本地计算显著大于同步开销”的尺度。真正的并行算法优化，经常不是换一个神奇 API，而是重新选择计算图节点的粒度。

高性能计算的局部性结构

HPC 的典型任务来自数值密集型科学计算，例如物理模拟、天气预报、有限元、量子化学、线性代数求解和 AI 推理。它们能大规模并行，根源通常是物理世界或数学结构提供了局部性。

例如网格模拟：

每个网格点主要依赖邻近网格点
网格内部可以本地计算
边界处需要交换数据
每一轮 delta t 之后做同步

这和生产者-消费者或 DAG 执行模型并不冲突，只是规模更大：

单机线程: shared memory + lock/cv/barrier
多机集群: message passing + barrier/reduction

MPI 和 OpenMP 分别代表两类常见抽象：

#pragma omp parallel for
for (int i = 0; i < n; i++) {
    work(i);
}

OpenMP 让共享内存机器上的循环并行化非常直接；MPI 则显式表达多进程/多机器之间的消息传递。它们服务的是同一件事：把大规模计算拆成本地执行和边界通信。

Embarrassingly Parallel

有些问题几乎不需要同步，被称为 embarrassingly parallel。典型例子包括：

• Mandelbrot set 中每个像素的迭代计算。
• Monte Carlo 模拟中的独立采样。
• 视频逐帧处理。
• fork-based DFS / tree search 的部分场景。

这类问题的计算图几乎没有边：

input[i] -> output[i]

并行化主要问题不是同步正确性，而是任务分配、负载均衡、缓存局部性、I/O 吞吐和结果汇总。Mandelbrot 的每个像素独立，但不同像素迭代次数可能不同，因此静态均分也可能出现负载不均。

Linpack 与分块线性代数

HPC-China 100 / Top500 常用 Linpack 作为性能基准，它衡量的是大型稠密线性方程组 Ax = b 的求解能力。

这个基准重要，是因为大量科学计算最终会落到线性代数：

非线性物理系统
-> Newton method
-> 稀疏/稠密线性系统
-> 矩阵分解、矩阵乘、向量运算

线性代数适合优化的根源是可分块：

矩阵块 = 本地计算单元
块边界 = 数据依赖和通信

分块同时服务两个目标：

• 并行性：不同块可以分给不同核心、GPU 或机器。
• 局部性：块能更好地复用 cache、shared memory 或 HBM。

这也是后续 SIMD/GPU、AI 推理和 kernel fusion 的基础：不是“并行”这个词本身带来性能，而是把计算组织成硬件喜欢的局部访问模式。

并行算法的性能判断

一个并行化方案是否有意义，不能只看线程数，而要看瓶颈在哪里。粗略判断可以用：

T_total = T_local_compute + T_sync + T_comm + T_sched + T_imbalance

如果优化只增加线程数，却让 T_sync、T_comm 或 T_imbalance 急剧上升，总时间可能反而变差。

常见失败模式：

• 任务太细：调度成本大于计算。
• 共享热点：所有线程竞争同一个 counter、queue 或 lock。
• 负载不均：某些线程早早结束，等待慢线程。
• 通信过密：每一小步都跨线程/跨机器交换数据。
• 缓存抖动：false sharing 或频繁迁移同一 cache line。

并行算法的正确打开方式是先画计算图，再决定任务粒度、调度策略和同步边界。

并行数据结构的核心矛盾

并行算法可以把大部分计算变成本地任务，但系统里仍然存在大量数据结构操作密集的场景：

• 操作系统内核对象。
• 数据库索引和锁表。
• 网络服务器连接表。
• 游戏服务器状态表。
• 高频交易订单簿。
• 分配器中的 free list。

这些场景里，sum++ 不是可以忽略的小元数据，而是吞吐瓶颈本身。此时必须重新审视数据结构的语义保证。

强一致版本的 counter 语义是：

每次读都看到一个完全线性化的最新值。

但很多系统其实只需要弱一点的保证：

读到的值可以略旧，但不能离谱，最终必须收敛。

这个放松就是性能空间的来源。

Sloppy Counter

Sloppy counter 的思想是：每个线程先更新自己的局部计数，累计到阈值后再批量提交到全局计数。

#define BATCH 100

int sum;
int sum_local[MAX_TID];
mutex_t lk;

void T_sum(int tid) {
    if (++sum_local[tid] == BATCH) {
        mutex_lock(&lk);
        sum += sum_local[tid];
        mutex_unlock(&lk);
        sum_local[tid] = 0;
    }
}

这里放松的是实时可见性，不是最终正确性：

高频路径: local increment，无锁
低频路径: batch flush，上锁

如果 BATCH = 100，理想情况下只有约 1% 的更新会进入全局锁。吞吐提升来自两个方面：

• 大多数写入落在线程本地 cache line。
• 全局锁竞争频率下降两个数量级。

代价是读者看到的 sum 可能落后于真实总数，最大误差大致受 BATCH * 线程数 控制。工程里可以用时间阈值、主动 flush 或自适应 batch 在准确性和吞吐之间折中。

一致性放松的语义边界

Sloppy counter 不是“随便错一点”。它必须先定义清楚允许放松什么：

允许: 短时间读到旧值
禁止: 丢失已经提交的全局更新
禁止: 局部计数永远不合并
禁止: 退出线程时泄漏本地计数

适合 sloppy 的场景：

• 统计量、监控指标、近似 QPS。
• 点赞数、连接数、内存使用量的近似读。
• 内核 per-cpu counter。

不适合 sloppy 的场景：

• 银行账户余额。
• 引用计数的最后一次释放判断。
• 安全权限状态。
• 需要严格线性化的队列长度。

优化前必须先回答：这个数据结构的 correctness condition 是什么？如果应用真的需要严格 linearizability，就不能靠近似计数逃课。

Thread-Local Storage

手写 sum_local[MAX_TID] 有几个问题：

• 需要自己分配和管理线程编号。
• 容易出现越界、复用 tid、线程退出清理问题。
• 多个线程的局部计数可能落在同一 cache line，造成 false sharing。

语言和运行时提供了 TLS。下面写法表达的是“每个线程一份全局/静态状态”，具体关键字在 C/C++ 标准中略有差异：

thread_local int sum_local;

void T_sum() {
    if (++sum_local == BATCH) {
        mutex_lock(&lk);
        sum += sum_local;
        mutex_unlock(&lk);
        sum_local = 0;
    }
}

thread_local 的语义是：每个线程自动拥有该变量的一份独立实例。它不是普通栈变量；它更像“按线程复制的全局变量”。

这里要区分语言规则：C11 使用 _Thread_local，C23 才把 thread_local 作为标准拼写；C 的块作用域 TLS 声明通常还需要配合 static 或 extern。C++11 的 thread_local 规则更宽，可以出现在块作用域，但它仍然是线程存储期对象，不是每次函数调用重新创建的自动变量。课堂代码强调的重点是：TLS 不能按普通局部变量理解。

TLS 的实现机制

普通全局变量、栈变量和 TLS 变量的寻址模型不同：

int x;              -> x(%rip)       // 全局静态存储
void foo(){ int y;} -> y(%rsp)       // 当前线程栈
thread_local int z -> z(%fs)        // 当前线程 TLS 区

在 x86-64 Linux 上，线程控制块和 TLS 区通常通过 %fs 段寄存器定位。编译器把 thread_local 访问编译成“TLS base + 固定偏移”的访问。不同线程的 TLS base 不同，因此同一个变量名在不同线程中对应不同地址。

实现上还涉及：

• .tdata：带初始值的 TLS 数据。
• .tbss：零初始化的 TLS 数据。
• 线程创建时为新线程分配并初始化 TLS 区。
• 动态库中的 TLS 需要动态链接器协作。

所以 TLS 不是语法魔法，而是 ABI、编译器、链接器、线程库共同提供的一块 per-thread 存储机制。

TLS 的使用边界

TLS 适合保存“线程本地、可延迟合并”的状态：

• 局部计数器。
• allocator thread cache。
• per-thread buffer。
• 日志缓冲区。
• 随机数生成器状态。

但 TLS 也有边界：

• 线程退出时需要 flush 或析构，否则局部状态可能丢失。
• 大对象 TLS 会增加每个线程的内存占用。
• 在线程池中，TLS 生命周期绑定 worker，而不是逻辑请求。
• 跨线程迁移任务时，TLS 可能让状态跟着线程而不是任务走。

对 allocator、runtime、serving system 来说，最后一点尤其重要：如果逻辑请求在不同 worker 间迁移，线程本地缓存能提升局部吞吐，但也可能带来内存膨胀和负载不均。

锁拆分与数据结构局部性

并行数据结构的基本思路是避免“一把锁保护整个世界”。如果数据结构天然由多个独立部分组成，就可以把锁拆到更小粒度：

global lock          -> per-structure lock
per-structure lock   -> per-bucket lock
per-bucket lock      -> per-element lock / atomic

哈希表是最典型例子。hash(key) 把 key 映射到 bucket 后，不同 bucket 的操作通常可以并行：

bucket = hash(key) % N;
mutex_lock(&bucket_locks[bucket]);
operate(table[bucket], key);
mutex_unlock(&bucket_locks[bucket]);

这比全局锁更可扩展，因为互不相关的 key 不再竞争同一把锁。读多写少时，还可以用 reader-writer lock 允许多个 reader 并发。

但细粒度锁会把正确性问题重新带回来：

• 一个操作需要多个 bucket 时，必须规定锁顺序，否则会 ABBA。
• resize 会重建整个数组，和所有 bucket 操作冲突。
• open addressing 的 tombstone、删除、遍历和并发 resize 很难组合。
• 锁粒度越细，越需要明确每个不变量由谁保护。

所以并行数据结构不是“把锁拆小”这么简单，而是重新定义不变量的所有权。

原子指令与 Lock-Free 思路

如果一个操作能用单条或少量原子指令完成，就可以避免进入 mutex：

atomic_fetch_add(&cnt, 1);

原子操作减少了内核阻塞和调度开销，但并不自动带来无限扩展。多个核心反复修改同一个 atomic counter，仍然会竞争同一条 cache line；硬件必须在核心之间转移该 cache line 的独占权限。

因此：

atomic 解决的是阻塞和临界区管理问题；
local/sharding 解决的是共享 cache line 热点问题。

Lock-free list、queue、stack 常用 CAS 维护指针结构，但会引入 ABA、内存回收、hazard pointer、epoch reclamation 等生命周期问题。第 17 讲的 ABA/UAF 在这里会重新出现，而且更难调试。

Hash Table 的并发难点

哈希表看似天然适合 per-bucket lock，但真实实现有几个麻烦点。

第一，链式哈希和开放寻址的并发语义不同：

separate chaining: bucket 内链表/树可单独保护
open addressing: 查找路径可能跨多个槽位

开放寻址依赖探测序列，删除还需要 tombstone。并发删除、查找、插入会改变探测路径的语义；遍历时还可能看到中间状态。

第二，resize 是全局结构变化：

old array -> new larger array
rehash all keys
publish new table
retire old table