1. 项目概述：深入操作系统内核的并发之门

如果你正在学习操作系统，并且已经啃完了进程、内存管理和文件系统这些硬骨头，那么“多线程”这个主题的出现，往往意味着课程进入了另一个深水区。MIT 6.S081 的 Lab 7: Multithreading 正是这样一道分水岭。它不再满足于让你理解课本上的概念，而是要求你亲手在一个教学用的、但五脏俱全的类Unix内核——xv6中，实现用户级线程包和内核级线程的同步原语。这个实验的核心，是让你从“知道线程是什么”跃升到“理解线程如何被创造、调度以及安全地协作”。

简单来说，这个实验要解决两个核心问题：第一，如何在用户空间模拟出“轻量级进程”，即用户级线程，让多个执行流共享同一个地址空间，并能由用户程序自己决定切换时机（非抢占式）。第二，如何在内核中为真正的多线程（即内核线程，或由内核调度的线程）提供保护共享数据的“锁”，以及让线程间能够协调步伐的“条件变量”和“屏障”。这听起来抽象，但对应到现实世界，就像是你既要学会自己组织一场需要多人接力完成的手工项目（用户级线程调度），又要为一场多人同时进行的、需要共享工具和材料的竞赛制定公平且不会出错的规则（内核同步原语）。

通过完成这个实验，你收获的远不止是几行通过测试的代码。你会透彻理解线程控制块（TCB）如何保存现场、上下文切换的底层魔法究竟是哪些寄存器的搬运游戏、以及为什么一些看似简单的a = a + 1语句在多线程下会神秘出错。更重要的是，你会建立起对并发编程最根本的敬畏之心——数据竞争、死锁、活锁不再是纸面上的术语，而是你调试时一个个需要精心抚平的“坑”。无论你未来是从事底层系统开发、高性能计算，还是普通的应用后端开发，这里锤炼出的对并发本质的理解，都将是你技术武库中一件极为犀利的兵器。

2. 实验环境与前置知识梳理

在动手之前，确保你的战场准备就绪，并且对即将使用的“武器”有清晰的认知，能事半功倍。这个实验强烈依赖于你对 xv6 代码结构和之前几个实验的积累。

2.1 实验环境搭建与代码获取

实验通常在 MIT 课程提供的特定 xv6 代码分支上进行。你需要一个 Linux 或 macOS 环境，并安装好 RISC-V 的工具链（包括gcc、binutils和qemu模拟器）。获取代码后，一个标准的起点是切换到thread分支：

git fetch origin git checkout thread

这个分支已经包含了实验的骨架代码（如user/uthread.c和user/uthread_switch.S）以及需要你修改的内核文件（如kernel/proc.c、kernel/spinlock.c）。我建议在开始前，先make qemu确保基础环境能正常启动，然后通读一遍user/uthread.c和对应的uthreadtest.c，理解测试程序想让你实现的线程行为是怎样的。同时，在kernel/defs.h中查看相关函数（如acquire,release,sleep,wakeup）的声明，它们是你实现内核同步原语的接口。

2.2 必备的前置概念与 xv6 背景

这个实验不是零基础的。它假设你已经牢固掌握了以下内容，如果感到生疏，强烈建议回头复习：

1. C 语言与指针：尤其是函数指针、结构体指针和内存操作。线程切换的本质就是操作一堆指针。
2. xv6 的进程模型：在 xv6 中，一个“进程”由struct proc定义，包含了内核栈、用户页表、状态、上下文（struct context）等。struct context保存了被调用者保存寄存器（ra,sp,s0-s11），这是上下文切换的关键。你需要深刻理解kernel/proc.c中的scheduler()函数和swtch()函数是如何协作完成进程切换的，因为用户级线程的切换是它的一个简化版。
3. 汇编基础（特别是 RISC-V）：虽然不需要写很复杂的汇编，但你必须能读懂kernel/swtch.S中的几行代码，明白swtch如何保存和恢复寄存器上下文。用户级线程切换的汇编部分（uthread_switch.S）需要你仿照实现。
4. 并发的基本问题：理解什么是数据竞争（两个线程同时读写一个变量，结果不确定）、原子性（一系列操作不可分割）、临界区（访问共享资源的代码段）以及死锁（两个以上的线程互相等待对方持有的资源）。

如果你对上述任何一点感到模糊，直接开始编码会很痛苦。我的经验是，花上半天时间，带着问题重新阅读 xv6 书中关于进程和调度的章节，并用 gdb 跟踪一次进程切换的全过程，之后的实验你会感到豁然开朗。

3. 核心任务一：实现用户级线程包

这是实验的第一部分，也是最直观的部分。目标是在用户空间实现一个协作式（非抢占）的线程系统。所有线程共享同一个进程的地址空间，由线程库而非内核来负责调度。这就像在一个大房间里，有几组人（线程）在完成不同的任务，他们自愿地（thread_yield）或在完成某项工作后（thread_exit）把房间的使用权让给下一组人。

3.1 线程控制块（TCB）与状态机设计

一切始于定义线程的状态。我们需要一个结构体来代表一个线程，通常称为线程控制块（Thread Control Block）。在user/uthread.c中，你需要定义struct thread。

struct thread { char stack[STACK_SIZE]; /* 每个线程独有的栈 */ int state; /* 状态：RUNNING, READY, SLEEP, DEAD */ struct context context; /* 切换时需要保存/恢复的寄存器上下文 */ };

关键设计点：

• 栈：每个线程必须有自己独立的栈空间，用于存放函数调用链、局部变量等。这是线程“独立执行流”的物理基础。STACK_SIZE需要足够大（比如 4096 字节），但也不能浪费。
• 状态：一个简单的状态机就够了。RUNNING（正在执行），READY（就绪，可被调度），SLEEP（等待某事件），DEAD（已结束，资源可回收）。状态转换是调度器工作的依据。
• 上下文：这是精髓所在。struct context在 xv6 中已经定义（kernel/proc.h），它通常只保存被调用者保存寄存器（Callee-saved registers），如ra（返回地址）、sp（栈指针）、s0-s11。因为按照 RISC-V 调用约定，函数可以自由使用调用者保存寄存器（Caller-saved registers），如a0-a7,t0-t6，如果被切换的线程正在使用它们，那应该由它的调用者（C代码）来保存。

注意：这里最容易混淆的是“为什么上下文只保存一部分寄存器？”。你可以这样类比：假设你（调度器）要打断一个正在画画的人（线程A），让他去休息，换另一个人（线程B）来画。你只需要帮A记下他画到哪了、他的专用画笔放在哪（这相当于ra,sp,s0-s11，是A的“长期工作状态”）。至于他手上正拿着的某支公共颜料（相当于a0,t0等临时寄存器），他要么自己用完放回原处（调用者保存约定），要么弄脏了也没关系，因为B来的时候会拿新的。内核的进程切换也遵循同样的约定。

3.2 线程创建与初始上下文构造

thread_create函数负责创建一个新线程。它接受一个函数指针func和参数arg。它的核心工作是为新线程“布置好舞台”，使得当它第一次被调度上场时，能正确地开始执行func(arg)。

int thread_create(void (*func)(void*), void *arg) { struct thread *t; // 1. 找到一个空闲的TCB结构（状态为DEAD的） for (t = all_thread; t < &all_thread[MAX_THREADS]; t++) { if (t->state == DEAD) break; } if (t == &all_thread[MAX_THREADS]) return -1; // 创建失败 // 2. 初始化新线程的栈指针 // 栈是向下增长的，所以初始栈指针指向栈顶（数组末尾） memset(t->stack, 0, STACK_SIZE); t->context.sp = (uint64)&t->stack[STACK_SIZE]; // 3. 关键步骤：在栈上“伪造”一个返回现场 // 使得第一次切换到该线程时，能“返回”到我们想要的函数。 // 在RISC-V中，ra寄存器保存返回地址。当swtch恢复上下文后，ret指令会跳转到ra。 // 我们需要将ra设置为目标函数的地址。 t->context.ra = (uint64)func; // 同时，按照调用约定，函数的第一个参数通过a0寄存器传递 // 我们需要在切换后，让a0的值等于arg。但上下文不保存a0（调用者保存寄存器）。 // 技巧：我们可以将arg放在栈上某个约定位置，或者更简单的方法—— // 我们可以将一个“启动胶水函数”的地址赋给ra，由这个胶水函数来设置a0并调用func。 // 但xv6的uthread通常采用另一种方法：直接设置上下文的a0（虽然context不包含a0，但我们可以扩展context或使用其他方式）。 // 这里为了概念清晰，我们假设通过某种方式（例如在栈上放置arg，并将ra指向一个包装器）实现了参数传递。 // 4. 设置线程状态为就绪 t->state = READY; return 0; }

这里的难点在于理解“第一次切换”。线程并非从func的第一条指令开始执行，而是从swtch恢复上下文后的ret指令开始。那个ret会跳转到ra寄存器的值。所以，我们把ra设为func，就相当于告诉线程：“你被切换过来后，要做的第一件事就是去执行func。” 参数传递则需要一点额外的技巧，比如在栈上预留空间存放arg，并将ra指向一个小的汇编桩（stub），这个桩从栈上加载参数到a0，再跳转到func。

3.3 线程调度与上下文切换实现

调度器（thread_schedule）的任务是从就绪（READY）线程中选出一个来运行。这里实现的是最简单的轮转调度。切换的核心是thread_switch函数，它需要用汇编编写，保存当前线程的上下文，并恢复目标线程的上下文。

调度器 (thread_schedule):

void thread_schedule(void) { struct thread *t, *next_thread; // 寻找当前线程的下一个就绪线程 // ... (轮转调度逻辑) if (next_thread == 0) { // 没有就绪线程，可能退出或等待 } // 进行切换 thread_switch(&(current_thread->context), &(next_thread->context)); }

上下文切换汇编 (user/uthread_switch.S): 这是整个用户级线程的“魔法”发生地。你需要参考kernel/swtch.S。

.text .globl thread_switch thread_switch: /* 保存当前线程的上下文到第一个参数（a0）指向的struct context */ sd ra, 0(a0) sd sp, 8(a0) sd s0, 16(a0) sd s1, 24(a0) /* ... 保存所有s寄存器 s2-s11 ... */ /* 恢复下一个线程的上下文从第二个参数（a1）指向的struct context */ ld ra, 0(a1) ld sp, 8(a1) ld s0, 16(a1) ld s1, 24(a1) /* ... 恢复所有s寄存器 s2-s11 ... */ ret /* 关键！这将跳转到新线程的ra地址，即新线程要执行的函数 */

实操心得：在编写uthread_switch时，最常见的错误是保存和恢复的寄存器列表与struct context的定义不匹配。务必逐字节对照kernel/proc.h中的struct context定义，确保顺序、数量完全一致。另一个坑是忘记设置初始的sp。如果新线程的sp没有指向一个有效的栈空间，一旦执行任何 push 操作或者函数调用，立刻就会访问非法内存导致崩溃。

3.4 线程让出与退出

thread_yield是协作式调度的关键。当前运行线程主动调用它，表示“我愿意放弃CPU”。它的实现很简单：将自身状态从RUNNING改为READY，然后调用thread_schedule()选择下一个线程运行。

thread_exit用于线程结束。它需要将自身状态标记为DEAD，并调度其他线程。这里有一个关键问题：一个线程退出后，它的栈和 TCB 结构是否可以立即回收？在协作式调度下，通常可以，因为退出操作是线程自己调用的，它不会再被调度。但更健壮的做法是，在调度器发现一个DEAD线程时，再回收其资源，或者设计一个简单的垃圾回收机制。

4. 核心任务二：实现内核同步原语

完成了用户级的“玩具”线程系统后，第二部分将直面真实内核中多线程带来的挑战。xv6 内核本身就可能被多个CPU核心同时执行（如果支持SMP），或者被中断处理程序打断，这些并发执行流都会访问共享的内核数据结构。如果没有同步机制，数据损坏是必然的。这部分实验就是要在 xv6 内核中实现锁（Lock）和条件变量（Condition Variable）等同步原语。

4.1 自旋锁的实现与关键考量

自旋锁（Spinlock）是最基础的同步原语。当一个线程试图获取一个已被持有的锁时，它会在一个循环中“自旋”等待，直到锁被释放。在 xv6 中，你需要完善kernel/spinlock.c中的acquire和release函数。

锁的结构体struct spinlock通常包含两个关键字段：一个表示锁是否被持有的locked字段，和一个用于调试的name字段。实现的核心是使用 RISC-V 的原子指令amoswap（原子性的交换内存和寄存器值）来实现acquire的原子性测试与设置。

void acquire(struct spinlock *lk) { // 在获取锁之前，需要关闭中断。 // 否则，如果持有锁的线程被中断，中断处理程序又试图获取同一把锁，就会导致死锁。 push_off(); // 关闭中断，并记录之前的开/关状态（用于嵌套） // 使用原子操作循环尝试获取锁 while(__sync_lock_test_and_set(&lk->locked, 1) != 0) { // 自旋等待。在实际系统中，这里可能会插入pause指令以减少CPU能耗和总线冲突。 } // 内存屏障：确保在获得锁之后的操作，不会因为CPU乱序执行而被重排到获得锁之前。 __sync_synchronize(); // 记录持有此锁的CPU（用于调试和死锁检测） lk->cpu = mycpu(); }

__sync_lock_test_and_set是 GCC 提供的内建函数，它原子地将lk->locked设置为1，并返回其旧值。如果旧值是0，表示锁之前是空闲的，我们成功获取；如果是1，表示锁正被占用，我们继续循环。

release函数则相对简单，但顺序很重要：

void release(struct spinlock *lk) { // 确保释放锁的就是持有它的CPU（调试用） if(!holding(lk)) panic("release"); lk->cpu = 0; // 内存屏障：确保锁释放之前的所有操作，对获得锁的其他CPU是可见的。 __sync_synchronize(); // 原子地将锁置为0。使用带有release语义的原子操作。 __sync_lock_release(&lk->locked); // 恢复之前的中断状态 pop_off(); }

注意事项：

1. 中断控制：acquire中关闭中断是必须的。想象一下，一个内核线程持有锁修改数据，此时时钟中断发生，中断处理程序也需要访问同一数据并尝试获取锁，就会自旋等待。但持有锁的线程被中断打断了，永远无法继续执行到release，这就形成了死锁。关闭中断可以防止当前CPU被中断处理程序打断。
2. 内存屏障：现代CPU和编译器为了性能会进行指令重排。__sync_synchronize()是一个全内存屏障，它确保屏障前的所有内存操作在屏障后的操作之前完成。这对于锁的“互斥”语义至关重要。没有它，临界区内的代码可能被重排到锁外执行，或者锁的获取操作被重排到临界区之后，完全破坏了锁的意义。
3. 自旋的代价：自旋锁在锁被短期持有时效率高（避免了线程切换的开销）。但如果锁被长期持有，自旋会白白浪费CPU周期。因此，自旋锁通常用于内核中保护非常短小的临界区。

4.2 睡眠锁的设计与取舍

自旋锁在等待时会持续占用CPU，这不适合可能长时间持有的锁。xv6 因此引入了睡眠锁（Sleeplock）。睡眠锁在争用时，会让当前线程睡眠（放弃CPU），当锁释放时再唤醒等待的线程。这类似于用户态常用的互斥锁（Mutex）。

睡眠锁通常在自旋锁的基础上实现。struct sleeplock包含一个自旋锁lk用于保护睡眠锁自身的内部状态（如锁状态、等待队列），以及一个表示锁是否被持有的字段locked。

acquiresleep的大致逻辑：

void acquiresleep(struct sleeplock *lk) { acquire(&lk->lk); // 先获取保护内部状态的自旋锁 while (lk->locked) { // 锁已被占用，当前线程需要睡眠 sleep(lk, &lk->lk); // 睡眠，并释放自旋锁lk.lk // 被唤醒后，重新获取自旋锁，继续检查locked状态 } lk->locked = 1; // 获得睡眠锁 release(&lk->lk); // 释放内部的自旋锁 }

sleep和wakeup是 xv6 内核提供的底层原语。sleep(chan, lock)将当前线程挂起在等待通道chan上，并释放lock（这个lock必须是自旋锁）。wakeup(chan)唤醒所有在chan上等待的线程。这里的关键是，从while循环检查到调用sleep之间，必须持有保护状态的自旋锁，否则可能会丢失一次wakeup（这就是“丢失唤醒”问题）。

4.3 条件变量的实现与应用模式

条件变量（Condition Variable）用于线程间的等待与通知，它总是与一个互斥锁（在xv6内核中通常用睡眠锁）一起使用。经典的使用模式是：

acquiresleep(&lock); // 获取互斥锁 while (condition_is_false) { cond_wait(&cv, &lock); // 等待条件，会释放lock并睡眠 } // 条件满足，执行操作... releasesleep(&lock); // 释放互斥锁

cond_wait的实现与sleep类似，但抽象层次更高。它内部会调用sleep。对应的cond_signal用于唤醒一个等待在该条件变量上的线程，cond_broadcast唤醒所有。

实现条件变量的核心在于理解“管程”（Monitor）模型。条件变量本身不包含状态，它只是一个等待队列。状态由程序员用共享变量来定义（上面的condition_is_false）。cond_wait的原子性在于：它同时完成了“释放锁”和“进入睡眠”这两个操作，这两个操作之间不会被其他线程插入，从而保证了在调用cond_wait之前对条件的判断，与进入睡眠的状态是一致的，避免了“丢失唤醒”。

4.4 屏障的实现及其应用场景

屏障（Barrier）是另一种同步机制，它要求一组线程都到达某个点后才能继续执行。这在并行计算中非常常见，比如并行算法的每个阶段结束后需要同步。

一个简单的屏障实现需要一个计数器n记录总线程数，一个计数器count记录已到达屏障的线程数，以及一个保护它们的锁。

struct barrier { struct spinlock lock; int n; // 需要等待的总线程数 int count; // 当前已到达的线程数 int round; // “代”数，用于区分连续的屏障调用 }; void barrier(struct barrier *b) { acquire(&b->lock); b->count++; if (b->count < b->n) { // 不是最后一个到达的线程，需要睡眠等待 int my_round = b->round; // 记录当前的“代” while (b->round == my_round) { sleep(&b->round, &b->lock); // 在round这个通道上睡眠 } } else { // 最后一个到达的线程，唤醒所有人并进入下一代 b->count = 0; b->round++; // 增加“代”数，这样上一代睡眠的线程就会退出循环 wakeup(&b->round); } release(&b->lock); }

这里使用round（代）的概念非常巧妙。它解决了“复用”问题：当所有线程被唤醒并通过第一次屏障后，count被重置为0。如果没有round，先快速执行完再次调用barrier的线程，可能会错误地唤醒还在上一轮屏障中睡眠的慢线程。通过增加round，每个线程在睡眠前记录当前的round值，只有被唤醒后看到的round不同了，才说明是新的一轮唤醒，从而可以正确退出。

5. 调试多线程程序的核心策略与工具

并发bug因其非确定性和难以复现而臭名昭著。在完成这个实验时，你几乎一定会遇到死锁、数据竞争等问题。掌握有效的调试策略比写出代码更重要。

5.1 理解并发Bug的常见模式

1. 数据竞争：最简单的例子是多个线程对同一个全局变量进行count++操作。这个操作不是原子的，它对应多条机器指令（读、加、写）。线程交错执行会导致最终结果小于预期。排查方法：仔细检查所有共享变量，确保每一次访问（读或写）都在锁的保护之下。使用printf打印变量值，观察异常。
2. 死锁：两个或多个线程互相持有对方所需的资源而无限等待。在xv6中常见于锁的获取顺序不一致。例如，线程A按顺序获取锁L1、L2，线程B按顺序获取L2、L1，就可能发生死锁。排查方法：为所有锁定义一个全局的获取顺序，并严格遵守。使用 xv6 内置的锁检测工具（如holding函数和lk->cpu记录）来追踪锁的持有者。
3. 丢失唤醒：发生在使用条件变量或睡眠/唤醒机制时。线程A检查条件为假，准备睡眠；但在它调用sleep()释放锁并真正进入睡眠状态之前，线程B修改了条件并调用了wakeup。这个wakeup对尚未睡眠的线程A无效。当A最终进入睡眠后，再也没有人来唤醒它。排查方法：确保“检查条件”和“进入睡眠”这个操作序列是在锁的保护下原子完成的。这正是cond_wait函数内部需要做的事情。
4. 原子性与内存可见性：即使使用了锁，也要注意某些操作本身是否需要原子性。例如，对一个复杂结构体的赋值可能不是原子的，如果另一个线程读到半新半旧的状态就会出错。此外，在多核CPU上，一个CPU写入的数据可能不会立即被另一个CPU看到（内存可见性问题），这需要通过内存屏障（如__sync_synchronize()）来解决。

5.2 利用 xv6 内置功能与 printf 调试

xv6 虽然简单，但提供了一些有用的调试支持：

• panic 与 printf：在内核代码中插入printf是最直接的调试手段。你可以打印线程ID（myproc()->pid）、CPU ID（cpuid()）、锁的状态等。panic函数可以让你在检测到非法状态时立即停止并打印调用栈。
• 死锁检测：在acquire函数中，xv6 会记录持有锁的CPU (lk->cpu)。你可以扩展这个功能，在acquire时检查是否已经持有了这把锁（重入），或者实现一个简单的锁依赖图检测（对于教学实验来说可能较复杂，但思考这个过程很有益）。
• QEMU 与 GDB：这是最强大的工具。你可以使用make qemu-gdb启动 xv6，并在另一个终端用 GDB 连接。可以设置断点（如b acquire）、单步执行汇编、查看内存和寄存器状态。当系统死锁时，通过Ctrl-C中断 QEMU，在 GDB 中使用backtrace查看每个CPU的调用栈，就能清楚地看到哪些线程卡在哪个锁上。

5.3 设计可测试的代码与压力测试

并发bug往往在特定时序下出现。为了增加复现概率，你需要：

• 增加交错可能性：在acquire、release、thread_yield等关键函数中，可以插入一些无用的循环或printf来人为增加线程切换的几率，放大竞争窗口。
• 编写压力测试：不要只满足于通过提供的测试用例（如uthreadtest.c或ph.c）。自己编写更激进的多线程测试，比如创建更多线程、进行更多次的锁操作、让线程以随机顺序获取锁等。
• 使用随机性：在测试程序中引入rand()来随机决定线程的操作顺序或睡眠时间，让每次运行都有不同的交错，长时间运行（“烤机”）有助于发现深藏的bug。

6. 从实验到现实：多线程编程的思维延伸

完成这个实验后，你应该对线程和同步有了刻骨铭心的理解。但实验室环境与现实生产环境仍有距离。了解这些延伸知识，能帮助你更好地将所学应用于实际。

6.1 用户级线程与内核线程的对比

我们实验的第一部分实现了用户级线程（ULT），第二部分则是在内核中为内核线程（KLT）提供同步支持。它们的区别是系统设计的经典话题：

• 调度主体：ULT由用户态运行时库调度，KLT由内核调度器调度。
• 切换开销：ULT的上下文切换仅需保存/恢复用户寄存器，无需陷入内核（模式切换），速度极快。KLT的切换需要内核介入，开销大。
• 阻塞影响：如果一个ULT发起系统调用（如I/O）而阻塞，内核会认为整个进程阻塞，该进程下的所有ULT都无法运行（因为内核感知不到它们）。这就是所谓的“一个阻塞，全家遭殃”。而KLT中，一个线程阻塞不会影响同进程的其他线程。
• 并行性：ULT无法利用多核CPU，因为内核只把一个进程调度到一个CPU上。KLT可以被调度到不同的CPU上真正并行执行。

现代编程语言（如Go）的“goroutine”是一种改进的ULT（或称M:N线程模型），它通过一个运行时系统，将大量goroutine映射到少量内核线程上，并结合非阻塞I/O，既获得了ULT的轻量，又避免了阻塞问题。

6.2 锁的粒度与性能权衡

锁是保护数据安全的重器，但用不好就会成为性能瓶颈。你需要思考锁的粒度。

• 粗粒度锁：用一把大锁保护整个复杂的数据结构或模块。简单安全，但并发度低，容易成为性能热点。
• 细粒度锁：用多把锁分别保护数据结构的不同部分。并发度高，但设计复杂，容易引发死锁，且加锁/解锁操作本身也有开销。

选择的原则是：在保证正确性的前提下，使用尽可能细的锁，但不要过度优化。通常先从一把简单的锁开始，证明正确性，再通过性能剖析（profiling）找到真正的热点，有针对性地进行细粒度优化。

6.3 无锁编程与乐观并发控制

锁是悲观的，它假设冲突总会发生，所以先加锁排除他人。另一种思路是乐观的：先进行操作，在最后提交时检查是否有冲突，如果有则回滚重试。这就是乐观并发控制，在冲突不频繁的场景下性能更好。

比较并交换（Compare-and-Swap, CAS）是硬件支持的原子操作，是无锁数据结构的基础。例如，无锁的栈入栈操作：

void push(node_t *new_node) { node_t *old_top; do { old_top = top; // 读取当前栈顶 new_node->next = old_top; } while (!CAS(&top, old_top, new_node)); // 原子地比较top是否仍为old_top，是则替换为new_node }

CAS 避免了使用锁，但编写正确的无锁算法极其困难，需要深厚的并发知识和对内存模型的深刻理解。对于绝大多数应用，正确使用锁是更务实的选择。

6.4 内存模型与顺序一致性

这是我们实验中内存屏障 (__sync_synchronize()) 背后的深层理论。现代CPU为了性能，会对指令进行乱序执行（Out-of-Order Execution），编译器也会进行指令重排。这导致在多线程视角下，代码的执行顺序可能与程序顺序不一致。

顺序一致性是最容易理解的内存模型：所有线程看到的整个系统的执行顺序是一致的，且每个线程内部的操作顺序得到保持。但这会严重限制硬件和编译器的优化。

松弛内存模型（如 C++11 和 Rust 的内存模型）则更加复杂，它定义了不同内存操作（读、写）之间的各种顺序约束（如 acquire-release 语义）。我们实验中使用的__sync_synchronize()是一个全屏障，它保证了最强的顺序，但代价也最高。在实际开发中，应该根据需要使用更精细的内存序（如std::memory_order_acquire,std::memory_order_release），在保证正确性的同时获得更好的性能。

理解内存模型是编写高性能、可移植并发代码的终极挑战。MIT 6.S081 的这个实验为你打开了这扇门，让你看到了门后世界的复杂与精彩。它带给你的不仅仅是实现几个同步原语的能力，更是一种严谨的、对并发本质不断追问的思维方式。下次当你看到mutex.lock()或channel.send()时，你的脑海中会自然地浮现出寄存器、上下文、原子指令和内存屏障的图景——这才是这个实验最宝贵的财富。