后面出来工作后的几次 PyCon 都有着或多或少的原因没有参加。今年孤身一人的我好像也没有什么不参加的理由了，我毅然的在论坛上点击了「参与」的投票

扬帆起航

很荣幸这次收到 Grey 的邀请在代码厨房的分会场上介绍一下 APIFlask，思前想后发觉自己已经3年没有参与这个项目了，让我来介绍它自觉难以胜任、有失偏颇。

我更想从轻松、有意思的角度来切入，讲讲我与 APIFlask 的相遇、相识、相知，再讲讲怎么在工作中的落地，从而引申出 APIFlask 的一些特性。

用一种聊天的方式而不是分享的方式来讲述，为此我最后将主题改为「我与 APIFlask 的故事」

由于身在职场中，不可避免的存在雇主与雇员的关系，尽管我以个人身份参加。为此我还需要在公司内部审批报备，我为了让这件事看上去比较“正规”，邮件的标题我还使用了《关于受邀在PyCon China 2025大会进行技术分享的参会报备申请​》 :p

所幸各级领导都挺支持与赞同我这次的行程，让我感受到公司还是很鼓励员工去参与各种大会、分享。

大乡里进城

本着来都来了的想法，我提前一天便早早到达上海。可能是（就是）不用上班的缘故，这天我居然没有赖床，开开心心的洗漱完出发去机场。还记得那天和朋友说，路上的空气都是甜的。

由于预算的问题我这次飞的是浦东机场，由于见识浅薄错过了磁悬浮，坐的市域铁进市区。后面听朋友说这是全球唯一的正在运营的磁悬浮，有点可惜但也无妨，又有去上海的理由了,不是吗？

晚上我和朋友约在了外滩的一家餐厅碰头，吃的是云南菜，让我想到了最近热议的云贵川 bistro 与上海主理人，我同事甚至打趣说我们是代码数据搬运主理人 :p

饭后我们坐观光车绕着外滩兜了一圈，我们发觉这个线路不太对劲，没什么东西好看的，好在我们快睡着的时候回到了起点。这天我打卡了上海保卫塔，和平饭店、永安百货等著名的地点。由于第二天的行程比较重要，我们早早的结束了这天的行程，回旅店休息了。

PyCon China 与美丽的邂逅

或许是水土不服的缘故，早上起来肚子不舒服导致出门的时间耽误了，但所幸没有错过什么重要的环节。

最激动的终于能见到神秘的 grey 了，在我和 grey 碰头没多久，厨委会的其他人也到了，大型的网友面基现场。

苏雄和高佳在策划代码厨房第一期的播客，邀请的嘉宾如无意外就是 grey 了，看着他们神采奕奕的讨论着如何策划，刹那间我仿佛回到了大学时和几个朋友做公众号时的场景，真是令人怀念。猛然间发现自己这三年好像失去了什么东西，那颗初心仿佛蒙上了厚重的灰尘，他们的讨论犹如一把鸡毛掸子扫去那厚重的尘埃，在此由衷的感谢他们，让我找回了初心。

下午的分享如期而至，我排在了最后一个讲，前面几个项目的分享都十分的有趣，让我记忆深刻的是 yihong 老师做开源的收益是负200刀 XD，当然 yihong 的演讲非常棒，是我梦想中的演讲

第一次上台做分享，虽然做足了准备但还是免不了紧张，但后面回过头来看还是有不少东西没有讲到。不过人无完人，没什么事情是能尽善尽美的，也是一次不错的体验与经历。当然也十分开心的解锁了新成就：在 PyCon 大会做分享

随着傍晚的到来，大会也落下帷幕，今天收获颇丰，除了干货满满的知识，还认识的了很多有意思的人。

秋天的到来，总是伴随着一种特殊的情感，那种既温柔又略带忧伤的感觉，在每一个秋日的清晨和黄昏里悄然蔓延。秋天是一个让人沉思的季节，树叶渐渐变黄，微风轻拂，带来丝丝凉意，仿佛在提醒我们时间的流逝和生命的无常。

秋天是一年中我最喜欢的季节，清爽、静逸是我对它的标签。我很喜欢走在铺满落叶的小路上，脚下发出轻微的沙沙声让人感觉到很舒服。

秋意浓时，总是容易引发人们对过去的追忆和对未来的思考，也忽然记起两年前写过的生, 活，在人生的每个十字路上貌似有很多选择但好像又没有选择。

秋意浓时同样也是寒冬的前兆，过去的三年，我总不是孤身一人，总有那份温情伴我左右，陪我走过那些寒冷的夜晚。然而，今年的秋天，似乎格外的萧瑟。那曾在身旁的身影，如今都成了回忆，渐行渐远，日渐模糊。

听闻，怀念很疼不忍触碰，于是，我佯装落笔轻松，想写一写黄昏的风，再写一写入夜的梦，怎奈，文字的轻柔却又格外沉重，这风一吹，总有当初的心动，而梦里，也总有回不去的曾经。

但我仍必须疾步前行，逝去的，莫再想，路正崎岖更漫长。宛如悉达多离开乔达摩，乔达文皈依佛门。正如悉达多所感：世界隐匿于周围，如同天际孤星，苏醒的最后颤栗，分娩的最后痉挛。

非死锁缺陷

非死锁缺陷主要可以概括为以下几个：

• 违反原子性

「违反原子性」是指违反了多次内存访问中预期的可串行性，也就是说临界区代码没有被锁保护起来（即代码段本意是原子的，但在执行中并没有强制实现原子性）。如下面的代码，解决方法也就是加锁:

1
2
3
4
5
6
7
8
9
10
11

Thread 1::
    // 判断和赋值应该是原子性的
    if (thd->proc_info)
    {
        ...
        fputs(thd->proc_info, ...);
        ...
    }

Thread 2::
    thd->proc_info = NULL;

• 违反顺序性

两个内存访问的预期顺序被打破了（即 A 应该在 B 之前执行，但是实际运行中却不是这个顺序）比如下面的这段代码中，如果 mState = mThread->State 语句先执行，则 mThread 为空。可以通过加条件变量(或信号量)解决：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Thread 1::
    void init()
    {
        ...
        mThread = PR_CreateThread(mMain, ...);
        ...
    }

Thread 2::
    void mMain(...)
    {
        ...
        mState = mThread->State;
        ...
    }

死锁缺陷

除了上面的缺陷外，死锁（deadlock）死一种并发系统中经典的问题。比如下面的代码就可能会出现死锁：

1
2
3
4
5
6
7

Thread 1:
lock(L1);
lock(L2);

Thread 2:
lock(L2);
lock(L1);

为什么发生死锁

• 复杂的依赖：以操作系统为例。虚拟内存系统依赖文件系统才能从磁盘读到内存页；文件系统依赖虚拟内存系统申请一页内存，以便存放读到的块。
• 封装：软件开发者一直倾向于隐藏实现细节，以模块化的方式让软件开发更容易。然而，模块化和锁不是很契合，以 Java 的 Vector 类和 AddAll()方法为例，我们这样调用这个方法：

1
2

Vector v1, v2;
v1.AddAll(v2);

在内部，这个方法需要多线程安全，因此针对被添加向量（v1）和参数（v2）的锁都需要获取。假设这个方法，先给 v1 加锁，然后再给 v2 加锁。如果另外某个线程几乎同时在调用 v2.AddAll(v1)，就可能遇到死锁。

产生死锁的条件

• 互斥：线程对于需要的资源进行互斥的访问（例如一个线程抢到锁）
• 持有并等待：线程持有了资源（例如已将持有的锁），同时又在等待其他资源（例如，需要获得的锁）
• 非抢占：线程获得的资源（例如锁），不能被抢占
• 循环等待：线程之间存在一个环路，环路上每个线程都额外持有一个资源，而这个资源又是下一个线程要申请的

预防死锁

• 循环等待：这个方法是最实用和常用的方法，就是让代码不产生循环等待的情况。最直接的方法就是获取锁的时候提供一个全序（total ordering），通过严格的加锁顺序避免了循环等待。
• 持有并等待：这个方法通过原子地抢锁来避免死锁问题，也就是说在用一把大锁把几个锁保护起来，但这么做可能会影响性能。
• 非抢占：解决非抢占就是要让线程能占用其他线程没在用的锁，不能占着茅坑不拉屎。具体来说trylock() 函数会尝试获取锁，当锁被占有时则返回-1。
• 互斥：如果不存在锁那么便不存在死锁。通过强大的硬件指令，我们可以构造出不需要锁的数据结构，这个强大的硬件指令就是「比较并交换（compare-and-swap）」。

下面是一个「比较并交换」的例子，在 *address 的值等于 expected 值时，将其赋值为 new：

1
2
3
4
5
6
7
8
9

int CompareAndSwap(int *address, int expected, int new)
{
    if (*address == expected)
    {
        *address = new;
        return 1; // success
    }
    return 0; // failure
}

假定我们想原子地给某个值增加特定的数量:

1
2
3
4
5
6
7
8
9
10
11
12

void AtomicIncrement(int *value, int amount)
{
    do
    {
        int old = *value;
    } while (CompareAndSwap(value, old, old + amount) == 0);

    /** 无同步操作
        int old = *value;
        *value = old + amount;
    */
}

一个更复杂的例子：链表插入。这是在链表头部插入元素的代码：

1
2
3
4
5
6
7
8

void insert(int value)
{
    node_t *n = malloc(sizeof(node_t));
    assert(n != NULL);
    n->value = value;
    n->next = head;
    head = n;
}

通过加锁解决同步：

1
2
3
4
5
6
7
8
9
10

void insert(int value)
{
    node_t *n = malloc(sizeof(node_t));
    assert(n != NULL);
    n->value = value;
    lock(listlock); // begin critical section
    n->next = head;
    head = n;
    unlock(listlock); // end of critical section
}

用比较并交换指令（compare-and-swap)来实现插入操作:

1
2
3
4
5
6
7
8
9
10

void insert(int value)
{
    node_t *n = malloc(sizeof(node_t));
    assert(n != NULL);
    n->value = value;
    do
    {
        n->next = head;
    } while (CompareAndSwap(&head, n->next, n) == 0);
}

这段代码，首先把 next 指针指向当前的链表头（head），然后试着把新结点交换到链表头。但是，如果此时其他的线程成功地修改了 head 的值，这里的交换就会失败，导致这个线程根据新的 head 值重试。

通过调度避免死锁

除了死锁预防外，有的场景死锁避免（avoidance）可能会更加合适，通过合理的调度避免产生死锁。比如下面的这个例子中，只要 T1 和 T2 (需要同一个锁的线程)不同时运行，就不会产生死锁。但这样就失去了并发性

检查和恢复

最后一种常用的策略就是允许死锁偶尔发生，检查到死锁时再采取行动。

提示：不要总是完美（TOM WEST 定律）

Tom West 是经典的计算机行业小说《Soul of a New Machine》的主人公，有一句很棒的工程格言：“不是所有值得做的事情都值得做好”。如果坏事很少发生，并且造成的影响很小，那么我们不应该去花费大量的精力去预防它。当然，如果你在制造航天飞机，事故会导致航天飞机爆炸，那么你应该忽略这个建议。

很多数据库系统使用了死锁检测和恢复技术。死锁检测器会定期运行，通过构建资源图来检查循环。当循环（死锁）发生时，系统需要重启。如果还需要更复杂的数据结构相关的修复，那么需要人工参与。

小结

本章中学习了并发编程中出现的缺陷的类型。同时也简要的讨论了死锁的发生和处理。死锁和并发编程可谓是想生相伴，在计算机发展的历史中，在一些通用库和系统中（比如Linux），都已经有了一些无等待的实现，但这仍然不够通用，并且设计一个新的无等待数据结构极为复杂，以至于不实用。也许，我们可以换个角度来看，一种新的无需任何锁的并发编程模型或许才是最好的解决方案。

信号量只是将锁和单值条件的条件变量封装在一起，所以它不是一个全新的概念，它能实现的事锁加条件变量都能实现。对于比较复杂情况下的条件判断无法使用信号量解决，因为其只内置了一个简单的整型的 value 条件。

信号量的定义

信号量是有一个整数值的对象，可以用两个函数来操作它。在 POSIX 标准中，是sem_wait()和 sem_post()。

1
2
3

#include <semaphore.h>
sem_t s;
sem_init(&s, 0, 1);

sem_init 用于初始化信号量，其中通过第三个参数将它的值初始化为1；第二个参数表示信号量是在同一个进程的多个线程共享的，我们可以看到在所有的例子中都设置为0，这个参数的值涉及到信号量的其他用法（比如跨进程的同步访问）。信号量初始化后，可以调用sem_wait()和 sem_post()来使用：

1
2
3
4
5
6
7
8
9

int sem_wait(sem_t *s) {
    decrement the value of semaphore s by one
    wait if value of semaphore s is negative
}

int sem_post(sem_t *s) {
    increment the value of semaphore s by one
    if there are one or more threads waiting, wake one
}

• sem_wait()要么立刻返回（调用 sem_wait()时，信号量的值大于等于 1），同时信号量减1，要么会让调用线程挂起，直到之后的一个 post 操作。
• sem_post()并没有等待某些条件满足。它直接增加信号量的值，如果有等待线程，唤醒其中一个。
• 当信号量的值为负数时，这个值就是等待线程的个数

二值信号量（锁）

首先我们看看信号量的第一种用法：用信号量作为锁。下面的代码中我们直接在临界区中用一对 sem_wait()/sem_post() 来包裹。但为了使这段代码正常工作，信号量的初始化是至关重要的。因为信号量是一个有整数值的对象，因此初始值应该是 1。代码如下：

1
2
3
4
5
6
7

sem_t m;
// 初值要为1
sem_init(&m, 0, 1);

sem_wait(&m);
// critical section here
sem_post(&m);

信号量用作条件变量

举一个具体的例子，假设一个线程创建另外一线程，并且等待它结束:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

sem_t s;

void *
child(void *arg)
{
    printf("child\n");
    sem_post(&s); // signal here: child is done
    return NULL;
}

int main(int argc, char *argv[])
{
    // X初始值应是0
    sem_init(&s, 0, X); // what should X be?
    printf("parent: begin\n");
    pthread_t c;
    Pthread_create(c, NULL, child, NULL);
    sem_wait(&s); // wait here for child
    printf("parent: end\n");
    return 0;
}

生产者/消费者问题

我们再尝试通过信号量来解决上一章提到的「生产者/消费者」问题，下面的代码通过三个信号量的组合使用解决了互斥与死锁两个问题，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

sem_t empty;
sem_t full;
sem_t mutex;

void *producer(void *arg)
{
    int i;
    for (i = 0; i < loops; i++)
    {
        // empty/full是一个条件变量，用于唤醒和等待
        // 不过可以自动形成等待队列，比条件变量方便
        sem_wait(&empty); // line p1
        // mutex是一个锁，用于商品队列的操作的保护
        // 锁的作用域很重要，尽可能缩小临界区来避免死锁和提高性能
        sem_wait(&mutex); // line p1.5 (MOVED MUTEX HERE...)
        put(i);           // line p2
        sem_post(&mutex); // line p2.5 (... AND HERE)
        sem_post(&full);  // line p3
    }
}

void *consumer(void *arg)
{
    int i;
    for (i = 0; i < loops; i++)
    {
        sem_wait(&full);  // line c1
        sem_wait(&mutex); // line c1.5 (MOVED MUTEX HERE...)
        int tmp = get();  // line c2
        sem_post(&mutex); // line c2.5 (... AND HERE)
        sem_post(&empty); // line c3
        printf("%d\n", tmp);
    }
}

int main(int argc, char *argv[])
{
    // ...
    sem_init(&empty, 0, MAX); // MAX buffers are empty to begin with...
    sem_init(&full, 0, 0);    // ... and 0 are full
    sem_init(&mutex, 0, 1);   // mutex=1 because it is a lock
    // ...
}

读写锁

并发编程中另一个经典的问题是源于对「更加灵活的锁定原语」的渴望，也就是说对更细粒度的锁的渴望。比如一个并发链表有很多插入和查找操作。插入会修改链表的状态，而查找只是读取。也就是说其实只要没有插入操作，我们可以并发的执行多个查找操作。

笔者认为所谓「更加灵活的锁定原语」或「如何提高锁的性能」等问题，其实都可以说是减少临界区代码，因为临界区代码其实只是并发编程中的一段「临时串行」的代码。而提高锁的性能、或者更加灵活的锁定原语，其实就是通过技巧来减少「临界区代码」，从而提高锁的效率。

比如：并发队列中将一把大锁拆分成入队/出队两把锁，从而提高了并发效率。这其实就是常说的减少锁的粒度

哲学家就餐问题

假定有 5 位“哲学家”围着一个圆桌。每两位哲学家之间有一把餐叉（一共 5 把）。哲学家有时要思考一会，不需要餐叉；有时又要就餐。而一位哲学家只有同时拿到了左手边和右手边的两把餐叉，才能吃到东西。如下图：

我们将上面提到的过程，用代码转译一下：

1
2
3
4
5
6

while (1) {
    think();
    getforks();
    eat();
    putforks();
}

因此我们可以看到，关键的挑战就是如何实现 getforks()和 putforks()函数，保证没有死锁，没有哲学家饿死，并且并发度更高（尽可能让更多哲学家同时吃东西）。我们首先定义一下这两个函数：

1
2

int left(int p) { return p; }
int right(int p) { return (p + 1) % 5; }

我们现在都知道，遇到并发问题第一个是加锁来解决，那么我们为每个动作都加锁：

1
2
3
4
5
6
7
8
9

void getforks() {
    sem_wait(forks[left(p)]);
    sem_wait(forks[right(p)]);
}

void putforks() {
    sem_post(forks[left(p)]);
    sem_post(forks[right(p)]);
}

但这个方案有一个问题，会形成死锁，每个人都拿着左手边的叉子就无法继续了（循环等待）。而解决这个问题最简单的方法，就是修改取餐叉的顺序，比如最后一个人先取右边的餐叉，然后再拿左边的，从而打破死锁（循环等待）：

1
2
3
4
5
6
7
8
9
10
11
12
13

void getforks()
{
    if (p == 4)
    {
        sem_wait(forks[right(p)]);
        sem_wait(forks[left(p)]);
    }
    else
    {
        sem_wait(forks[left(p)]);
        sem_wait(forks[right(p)]);
    }
}

如何实现信号量

最后我们用底层的同步原语（锁和条件变量），来实现自己的信号量：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

typedef struct _Zem_t
{
    int value;
    pthread_cond_t cond;
    // 对value的修改锁
    pthread_mutex_t lock;
} Zem_t;

// only one thread can call this
void Zem_init(Zem_t *s, int value)
{
    s->value = value;
    Cond_init(&s->cond);
    Mutex_init(&s->lock);
}

void Zem_wait(Zem_t *s)
{
    Mutex_lock(&s->lock);
    while (s->value <= 0)
        Cond_wait(&s->cond, &s->lock);
    // 在这里递减value，value值就不会小于0了。
    s->value--;
    Mutex_unlock(&s->lock);
}

void Zem_post(Zem_t *s)
{
    Mutex_lock(&s->lock);
    s->value++;
    Cond_signal(&s->cond);
    Mutex_unlock(&s->lock);
}

小结

信号量是编写并发程序强大而灵活的原语，信号量基于锁和条件变量，可以实现两者的功能。

• 作为锁时，可以自动管理等待队列。
• 作为条件变量时，免去了 while 判断是否需要等待的操作，因为内部包含了一个 value 值用于判断

比如在很多情况下，线程需要检查某一条件（condition）满意之后，才会继续运行。比如父线程等待子线程的join 函数。下面是一段自旋等待的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

void *child(void *arg)
{
    printf("child\n");
    // do someting...
    // 修改判断条件
    done = 1;
    return NULL;
}

// 要父线程等待子线程的话，需要加个自旋锁，并加上判断条件
int main(int argc, char *argv[])
{
    printf("parent: begin\n");
    pthread_t c;
    Pthread_create(&c, NULL, child, NULL); // create child
    // XXX how to wait for child?
    // 等待判断条件done为1(子线程执行完成)，（一直占着CPU，很浪费）
    while (done == 0)
        ; // 自旋等待
    printf("parent: end\n");
    return 0;
}

这个方案无疑是能解决问题的，但效率比较低，因为主线程会自旋检查，浪费 CPU 时间。那么如果有一种方法可以让父线程休眠，直到等待的条件满足才唤醒执行，无疑会更加高效。

定义和程序

而这样的一种锁和休眠等待的组合，已经为我们封装好了。线程可以使用条件变量（condition variable），来等待一个条件变成真。

条件变量是一个显式队列，当某些执行状态（即条件，condition）不满足时，线程可以把自己加入队列，等待（waiting）该条件。另外某个线程，当它改变了上述状态时，就可以唤醒一个或者多个等待线程（通过在该条件上发信号），让它们继续执行。具体用法如下：

1
2
3
4
5

// 声明
pthread_cond_t c
// 相关操作
wait()
signal()

wait()调用有一个参数，它是互斥量mutex。

条件变量一般要与锁一起使用，wait() 调用时，这个互斥量必须是已上锁状态（处于临界区内）。wait() 的职责是释放锁，并让调用线程休眠（原子地）。当线程被唤醒时（在另外某个线程发信号给它后），它必须重新获取锁(重新进入临界区)，再返回调用者。

实际应用时由条件和锁共同决定临界区，如果获得锁就进入临界区，但如果条件未满足，则暂时放弃锁退出临界区，直到被唤醒（且条件满足）时重新上锁进入临界区。典型的条件变量用法（伪代码）:

1
2
3
4
5
6

lock(&mutex);//进入临界区，保护done及其他临界资源
while (done == 0) // 判断条件，判断时必须保证在临界区内
    wait(&cond, &mutex);// 条件不满足时放弃锁，暂时退出临界区
// 条件满足时，进入真正的临界区
/* do somting... */
unlock(&mutex);// 退出临界区

需要注意：**发信号时总是持有锁，**尽管并不是所有情况下都严格需要，但有效且简单的做法，还是在使用条件变量发送信号时持有锁。虽然上面的例子是必须加锁的情况，但也有一些情况可以不加锁，而这可能是你应该避免的。因此，为了简单，请在调用 signal 时持有锁（hold the lock when calling signal）。

这个提示的反面，即调用 wait 时持有锁，不只是建议，而是 wait 的语义强制要求的。因为 wait 调用总是假设你调用它时已经持有锁、调用者睡眠之前会释放锁以及返回前重新持有锁。因此，这个提示的一般化形式是正确的：调用 signal 和 wait 时要持有锁（hold the lock when calling signal or wait），你会保持身心健康的。

生产者/消费者（有界缓冲区）问题

本章要面对的下一个问题，就是生产者/消费者问题（producer/consumer），有的也叫「有界缓冲区（bounded buffer）」问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

cond_t cond;
mutex_t mutex;

void *producer(void *arg)
{
    int i;
    for (i = 0; i < loops; i++)
    {
        Pthread_mutex_lock(&mutex);           // p1
        // 名义上的临界区，在lock之间
        if (count == 1)                       // p2
            Pthread_cond_wait(&cond, &mutex); // p3
        // 实际上的临界区，由于wait会释放锁退出临界区(被唤醒后重新上锁)，
        // 所以从这里开始才是真正的临界区
        put(i);                               // p4
        Pthread_cond_signal(&cond);           // p5
        Pthread_mutex_unlock(&mutex);         // p6
    }
}

void *consumer(void *arg)
{
    int i;
    for (i = 0; i < loops; i++)
    {
        Pthread_mutex_lock(&mutex);           // c1
        // 1. 此处存在问题，当有两个消费者（Cus1,Cus2）时，其中Cus1进入休眠，
        // Cus2正好在生产者生产后执行get把count消费掉，此时
        // 生产者又调用signal唤醒Cus1休眠的，直接执行了get发现
        // 没有count了,所以要把if改成while，wait出来还要再
        // 判断一次count
        // 2. 使用while带来另一个问题，Cus1消费后本该唤醒生产者，
        // 但如果唤醒了Cus2线程，因为没东西消费，Cus2也会等待，
        // 就会导致三个线程都在等待中。解决方法是设置两个条件变量，
        // 保证消费者唤醒生产者，生产者唤醒消费者
        if (count == 0)                       // c2
            Pthread_cond_wait(&cond, &mutex); // c3
        int tmp = get();                      // c4
        Pthread_cond_signal(&cond);           // c5
        Pthread_mutex_unlock(&mutex);         // c6
        printf("%d\n", tmp);
    }
}

可以看到上面的代码中使用 if 作为判断显然是不合理的，具体原因我写在注释中了。为此我们可以总结出一个关于条件变量使用的简单规则：「总是使用 while 循环（always use while loop）」。

其次便是通知是需要指向性的，消费者不应该唤醒消费者，而应该只唤醒生产者，反之亦然。

下面我们使用 while 来修改代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

int buffer[MAX];
int fill = 0;
int use = 0;
int count = 0;

void put(int value)
{
    buffer[fill] = value;
    fill = (fill + 1) % MAX;
    count++;
}

int get()
{
    int tmp = buffer[use];
    use = (use + 1) % MAX;
    count--;
    return tmp;
}
cond_t empty, fill;
mutex_t mutex;

void *producer(void *arg)
{
    int i;
    for (i = 0; i < loops; i++)
    {
        Pthread_mutex_lock(&mutex);            // p1
        while (count == MAX)                   // p2
            Pthread_cond_wait(&empty, &mutex); // p3
        put(i);                                // p4
        Pthread_cond_signal(&fill);            // p5
        Pthread_mutex_unlock(&mutex);          // p6
    }
}

void *consumer(void *arg)
{
    int i;
    for (i = 0; i < loops; i++)
    {
        Pthread_mutex_lock(&mutex);           // c1
        while (count == 0)                    // c2
            Pthread_cond_wait(&fill, &mutex); // c3
        int tmp = get();                      // c4
        Pthread_cond_signal(&empty);          // c5
        Pthread_mutex_unlock(&mutex);         // c6
        printf("%d\n", tmp);
    }
}

覆盖条件

下面来看一个例子，这是一个简单的多线程内存分配库，以下代码用于内存分配管理，free 后会唤醒 allocate 时因空间不够而等待的线程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// how many bytes of the heap are free?
int bytesLeft = MAX_HEAP_SIZE;

// need lock and condition too
cond_t c;
mutex_t m;

void *
allocate(int size)
{
    Pthread_mutex_lock(&m);
    while (bytesLeft < size)
        Pthread_cond_wait(&c, &m);
    void *ptr = ...; // get mem from heap
    bytesLeft -= size;
    Pthread_mutex_unlock(&m);
    return ptr;
}

void free(void *ptr, int size)
{
    Pthread_mutex_lock(&m);
    bytesLeft += size;
    Pthread_cond_signal(&c); // whom to signal??
    Pthread_mutex_unlock(&m);
}

考虑以下场景：假设目前没有空闲内存，线程 Ta 调用 allocate(100) ，接着线程 Tb 请求较少的内存，调用 allocate(10) 。Ta 和 Tb 都等待在条件上并睡眠，没有足够的空闲内存来满足它们的请求。

假定第三个线程 Tc 调用了 free(50)，当他发出信号唤醒等待线程时，因为不知道唤醒哪个线程，可能不会唤醒申请 10 字节的 Tb 线程，而是唤醒 Ta 线程，但该线程由于内存不够仍然等待。因此图中的代码无法正常的工作。

解决的方案也很直接：用使用 pthread_cond_broadcast()唤醒所有等待的线程。这样做，确保了所有应该唤醒的线程都被唤醒。当然，不利的一面是可能会影响性能。Lampson 和 Redell 把这种条件变量叫作覆盖条件（covering condition），因为它能覆盖所有需要唤醒线程的场景（保守策略）

小结

这一章引入了锁之外的另一个重要同步原语：条件变量。当某些程序状态不符合要求时，让线程进入休眠状态，避免不必要的空转（spin）

需要注意，条件变量并不是不需要锁。

并发计数器

下面先看一个简单的非并发的计数器，然后一步步的在此基础上构建一个并发安全且高性能的计数器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

typedef struct counter_t
{
    int value;
} counter_t;

void init(counter_t *c)
{
    c->value = 0;
}

void increment(counter_t *c)
{
    c->value++;
}

void decrement(counter_t *c)
{
    c->value--;
}

int get(counter_t *c)
{
    return c->value;
}

可以看到计数器的代码非常简单，而我们想其并发安全显而易见的方法便是在结构体中添加一把锁，在数据做修改操作的临界区代码添加上这把锁，修改后的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

typedef struct counter_t
{
    int value;
    pthread_mutex_t lock;
} counter_t;

void init(counter_t *c)
{
    c->value = 0;
    Pthread_mutex_init(&c->lock, NULL);
}

void increment(counter_t *c)
{
    Pthread_mutex_lock(&c->lock);
    c->value++;
    Pthread_mutex_unlock(&c->lock);
}

void decrement(counter_t *c)
{
    Pthread_mutex_lock(&c->lock);
    c->value--;
    Pthread_mutex_unlock(&c->lock);
}

int get(counter_t *c)
{
    Pthread_mutex_lock(&c->lock);
    int rc = c->value;
    Pthread_mutex_unlock(&c->lock);
    return rc;
}

这样做在多CPU环境下性能很差，因为这种锁导致了多 CPU 情况下也只允许一个线程在运行，其他都在自旋等待，没发挥出多 CPU 的优势。相当于退化成串行，并且还增加了锁的开销。理想情况下，虽然工作量增多，但并行执行后，完成任务的时间并没有增加。

可扩展的计数器（扩展的意思是支持多 CPU）

为了解决上面的问题，有一种解决方法称为：懒惰计数器（sloppy counter）

懒惰计数器通过多个局部计数器和一个全局计数器来实现一个逻辑计数器，其中每个 CPU 核心有一个局部计数器。具体来说，在 4 个 CPU 的机器上，有 4 个局部计数器和 1 个全局计数器。除了这些计数器，还有锁：每个局部计数器有一个锁，全局计数器有一个。

懒惰计数器的基本思想是这样的。如果一个核心上的线程想增加计数器，那就增加它的局部计数器，访问这个局部计数器是通过对应的局部锁同步的。因为每个 CPU 有自己的局部计数器，不同 CPU 上的线程不会竞争，所以计数器的更新操作可扩展性好。

为了保持全局计数器更新（以防某个线程要读取该值），局部值会定期转移给全局计数器，方法是获取全局锁，让全局计数器加上局部计数器的值，然后将局部计数器置零

局部转全局的频度，取决于一个阈值，这里称为 S（表示 sloppiness）。S 越小，懒惰计数器则越趋近于非扩展的计数器。S 越大，扩展性越强，但是全局计数器与实际计数的偏差越大。

在这个例子中，阈值 S 设置为 5，4 个 CPU 上分别有一个线程更新局部计数器 L1,…, L4。随着时间增加，全局计数器 G 的值也会记录下来。每一段时间，局部计数器可能会增加。如果局部计数值增加到阈值 S，就把局部值转移到全局计数器，局部计数器清零。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

typedef struct counter_t
{
    int global;                     // global count
    pthread_mutex_t glock;          // global lock
    int local[NUMCPUS];             // local count (per cpu)
    pthread_mutex_t llock[NUMCPUS]; // ... and locks
    int threshold;                  // update frequency
} counter_t;

// init: record threshold, init locks, init values
// of all local counts and global count
void init(counter_t *c, int threshold)
{
    c->threshold = threshold;

    c->global = 0;
    pthread_mutex_init(&c->glock, NULL);

    int i;
    for (i = 0; i < NUMCPUS; i++)
    {
        c->local[i] = 0;
        pthread_mutex_init(&c->llock[i], NULL);
    }
}

// update: usually, just grab local lock and update local amount
// once local count has risen by 'threshold', grab global
// lock and transfer local values to it
void update(counter_t *c, int threadID, int amt)
{
    pthread_mutex_lock(&c->llock[threadID]);
    c->local[threadID] += amt; // assumes amt > 0
    if (c->local[threadID] >= c->threshold)
    { // transfer to global
        pthread_mutex_lock(&c->glock);
        c->global += c->local[threadID];
        pthread_mutex_unlock(&c->glock);
        c->local[threadID] = 0;
    }
    pthread_mutex_unlock(&c->llock[threadID]);
}

// get: just return global amount (which may not be perfect)
int get(counter_t *c)
{
    pthread_mutex_lock(&c->glock);
    int val = c->global;
    pthread_mutex_unlock(&c->glock);
    return val; // only approximate!
}

并发链表

我们和上面一样，先添加一把大锁保证了并发安全，然后再进一步探讨如何优化性能：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

// basic node structure
typedef struct node_t
{
    int key;
    struct node_t *next;
} node_t;

// basic list structure (one used per list)
typedef struct list_t
{
    node_t *head;
    pthread_mutex_t lock;
} list_t;

void List_Init(list_t *L)
{
    L->head = NULL;
    pthread_mutex_init(&L->lock, NULL);
}

int List_Insert(list_t *L, int key)
{
    pthread_mutex_lock(&L->lock);
    node_t *new = malloc(sizeof(node_t));
    if (new == NULL)
    {
        perror("malloc");
        pthread_mutex_unlock(&L->lock);
        return -1; // fail
    }
    new->key = key;
    new->next = L->head;
    L->head = new;
    pthread_mutex_unlock(&L->lock);
    return 0; // success
}

int List_Lookup(list_t *L, int key)
{
    pthread_mutex_lock(&L->lock);
    node_t *curr = L->head;
    while (curr)
    {
        if (curr->key == key)
        {
            pthread_mutex_unlock(&L->lock);
            return 0; // success
        }
        curr = curr->next;
    }
    pthread_mutex_unlock(&L->lock);
    return -1; // failure
}

从代码中可以看出，插入函数入口处获取锁，结束时释放锁。如果 malloc 失败（在极少的时候），会有一点小问题，在这种情况下，代码在插入失败之前，必须释放锁。

我们调整代码，让获取锁和释放锁只环绕插入代码的真正临界区(缩小临界区)。前面的方法有效是因为部分工作实际上不需要锁，假定 malloc()是线程安全的，每个线程都可以调用它，不需要担心竞争条件和其他并发缺陷。只有在更新共享列表时需要持有锁。下面展示了这些修改的细节。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

void List_Init(list_t *L)
{
    L->head = NULL;
    pthread_mutex_init(&L->lock, NULL);
}

void List_Insert(list_t *L, int key)
{
    // synchronization not needed
    node_t *new = malloc(sizeof(node_t));
    if (new == NULL)
    {
        perror("malloc");
        return;
    }
    new->key = key;

    // just lock critical section
    pthread_mutex_lock(&L->lock);
    new->next = L->head;
    L->head = new;
    pthread_mutex_unlock(&L->lock);
}

int List_Lookup(list_t *L, int key)
{
    int rv = -1;
    pthread_mutex_lock(&L->lock);
    node_t *curr = L->head;
    while (curr)
    {
        if (curr->key == key)
        {
            rv = 0;
            break;
        }
        curr = curr->next;
    }
    pthread_mutex_unlock(&L->lock);
    return rv; // now both success and failure
}

现在已经能保证这个链表的并发安全了，想要解决性能问题，可以使用一种叫过手锁（hand-over-hand locking，也叫锁耦合，lock coupling），其原理十分简单，就是每个节点都有一个锁，替代之前整个链表一个锁。遍历链表的时候，首先抢占下一个节点的锁，然后释放当前节点的锁。

从理论上来说确实有点合理，但实际上在遍历的时候，每个节点都要加锁、解锁，而这个开销也是十分巨大的，很难说比单锁的方法快。即使有大量的线程和很大的链表，也不一定就比单锁快，它只适用于十分单一且特殊的场景，或者夹杂在某些方案里面。

并发队列

现在我们知道可以用标准的方法来创建一个并发安全的数据结构：添加一把大锁。现在队列这种数据结构其实和链表很像，只是队列的操作有限制，因此大锁这种方案我们跳过。我们来看看 Michael 和 Scott 设计的更并发的队列：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

typedef struct __node_t
{
    int value;
    struct __node_t *next;
} node_t;

typedef struct queue_t
{
    node_t *head;
    node_t *tail;
    pthread_mutex_t headLock;
    pthread_mutex_t tailLock;
} queue_t;

void Queue_Init(queue_t *q)
{
    // tmp是假结点
    node_t *tmp = malloc(sizeof(node_t));
    tmp->next = NULL;
    q->head = q->tail = tmp;
    pthread_mutex_init(&q->headLock, NULL);
    pthread_mutex_init(&q->tailLock, NULL);
}

void Queue_Enqueue(queue_t *q, int value)
{
    node_t *tmp = malloc(sizeof(node_t));
    assert(tmp != NULL);
    tmp->value = value;
    tmp->next = NULL;

    pthread_mutex_lock(&q->tailLock);
    q->tail->next = tmp;
    q->tail = tmp;
    pthread_mutex_unlock(&q->tailLock);
}

int Queue_Dequeue(queue_t *q, int *value)
{
    pthread_mutex_lock(&q->headLock);
    node_t *tmp = q->head;
    node_t *newHead = tmp->next;
    // 如果是假结点，则视为空
    if (newHead == NULL)
    {
        pthread_mutex_unlock(&q->headLock);
        return -1; // queue was empty
    }
    *value = newHead->value;
    q->head = newHead;
    pthread_mutex_unlock(&q->headLock);
    free(tmp);
    return 0;
}

这段代码十分巧妙，用到了两个锁和一个哨兵节点。一个锁负责队头，另一个负责队尾，使得入队出队操作可以并发执行。而哨兵节点是在初始化的时候分配的，利用它分开了头和尾的操作。

并发散列表

最后讨论的是一个广泛应用的数据结构——散列表，为了突出重点，这里不对扩缩容做深入：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#define BUCKETS (101)

typedef struct hash_t
{
    list_t lists[BUCKETS];
} hash_t;

void Hash_Init(hash_t *H)
{
    int i;
    for (i = 0; i < BUCKETS; i++)
    {
        List_Init(&H->lists[i]);
    }
}

int Hash_Insert(hash_t *H, int key)
{
    int bucket = key % BUCKETS;
    return List_Insert(&H->lists[bucket], key);
}

int Hash_Lookup(hash_t *H, int key)
{
    int bucket = key % BUCKETS;
    return List_Lookup(&H->lists[bucket], key);
}

这个散列表使用我们上面实现的并发链表，性能特别好。每个散列桶（每个桶都是一个链表）都有一个锁，而不是整个散列表只有一个锁，从而支持许多并发操作，其实就是分段加锁了。

这个简单的并发散列表扩展性（性能）极好，相较于单纯的链表。原因就是缩小了临界区，减少了不同线程间操作的冲突。

小结

并发其实并不意味着高性能，在实现并发数据结构时，先从最简单的开始（也就是加一把大锁），有性能问题的时候再做优化。关于最后一点，避免不成熟的优化（premature optimization），对于所有关心性能的开发者都有用。我们让整个应用的某一小部分变快，却没有提高整体性能，其实没有价值

锁的基本思想

lock()和 unlock()函数的语义很简单。调用 lock() 尝试获取锁，如果没有其他线程持有锁（即它是可用的），该线程会获得锁，进入临界区。当持有锁的线程在临界区时，其他线程就无法进入临界区。伪代码如下：

1
2
3
4
5
6
7

lock_t mutex;
...
lock(&mutex);
// 临界区代码(可能存在并发问题的代码）
// 比如全局变量的操作: balance = balance + 1
... 
unlock(&mutex);

Pthread 锁

POSIX 库将锁称为互斥量（mutex）使用代码如下：

1
2
3
4

pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&lock); // wrapper for pthread_mutex_lock()
balance = balance + 1;
pthread_mutex_unlock(&lock);

评价锁的几个指标

• 能否完成它的基本任务——互斥（mutual exclusion）
• 公平性（fairness）——当锁可用时，是否每个竞争的线程都有公平的机会抢到锁？
• 性能（performance）——锁竞争带来的时间开销，比如单 CPU 上竞争的开销的和多 CPU 上多个线程竞争时的开销，通过比较不同的场景，我们嗯更好的理解不同锁技术对性能的影响。

控制中断

控制中断是最早提供的互斥解决方案之一，其本质就是在执行临界区代码的时候关闭中断。这个方案是为单处理器系统开发的，代码如下：

1
2
3
4
5
6

void lock() {
    DisableInterrupts();
}
void unlock() {
    EnableInterrupts();
}

这样的方案的优点是简单、清晰易懂。但缺点却很多：

1. 要允许所有调用线程执行特权操作（打开/关闭中断），信任这种机制不会被滥用。但这是理想的情况，因为我们无法得知用户允许的程序是否可信任，因此该方案不适合作为通用方案。糟糕的情况比如有以下几个：
   1. 一个贪婪的程序可以在开始时就关闭中断，从而独占处理器。
   2. 更糟糕的情况是被恶意程序利用，调用 lock 后一直死循环，系统无法重新获得控制权，只能重启系统。
2. 不支持多处理器，如果多个线程允许在不同的 CPU 上，每个线程都试图进入同一个临界区，那么即便关中断也没用。当下多处理器已经很普遍了，因此需要方案更加通用。
3. 关中断导致中断丢失，这可能会导致严重的系统问题。比如磁盘完成了读取请求，正常应该会给个中断，但 CPU 因为关中断导致错失了这一中断，那么，操作系统如何知道去唤醒等待读取的进程？
4. 效率低，与正常的执行指令相比，现代 CPU 对于关闭/打开中断的代码执行的比较慢。

因此基于上述的情况，只在少数的情况下用开/关中断来实现互斥原语，比如操作系统本身会采用屏蔽中断的方式，保证访问自己数据结构的原子性或者避免复杂的中断处理情况，因为在操作系统内部它总是可信的，不存在信任问题。

「原语」是什么？个人简单的理解，原语是指操作系统层面提供的指令，一个原语中可能有很多个底层的指令，但操作系统帮我们确保了这些指令以原子的方式执行。

「硬件支持」测试并设置指令（原子交换）

锁的实现需要硬件支持，最简单的硬件支持是测试并设置指令（test-and-set instruction，TAS），也叫作原子交换（atomic exchange）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

typedef struct lock_t { int flag; } lock_t;

void init(lock_t *mutex) {
    // 0 -> lock is available, 1 -> held
    mutex->flag = 0;
}

void lock(lock_t *mutex) {
    while (mutex->flag == 1) // TEST the flag
        ; // spin-wait (do nothing)
    mutex->flag = 1; // now SET it!
}

void unlock(lock_t *mutex) {
    mutex->flag = 0;
}

上述代码中，每次 lock 会判断 flag 的值，也就是**测试并设置指令（test-and-set instruction）**中的test，然后判断成功才 set

但如果没有硬件辅助，也就是让测试并设置作为一个原子操作，会导致两个线程有可能同时进入临界区。

注意自旋等待spin-wait会影响性能

实现可用的自旋锁

自旋锁（spin lock）其实就是一直自旋（判断某个条件成立），直到锁可用。

在 SPARC 上，需要的指令叫 ldstub（load/store unsigned byte，加载/保存无符号字节）；在 x86 上，是 xchg（atomic exchange，原子交换）指令。但它们基本上在不同的平台上做同样的事，通常称为测试并设置指令（test-and-set）。

1
2
3
4
5

int TestAndSet(int *old_ptr, int new) {
    int old = *old_ptr; // fetch old value at old_ptr
    *old_ptr = new; // store 'new' into old_ptr
    return old; // return the old value
}

将测试并设置作为原子操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

typedef struct lock_t {
    int flag;
} lock_t;

void init(lock_t *lock) {
    // 0 indicates that lock is available, 1 that it is ld
    lock->flag = 0;
}

void lock(lock_t *lock) {
    while (TestAndSet(&lock->flag, 1) == 1)
        ; // spin-wait (do nothing)
}

void unlock(lock_t *lock) {
    lock->flag = 0;
}

评价自旋锁

现在我们来用之前提到的标准来评价基本的自旋锁：

• 锁最重要的一点是正确性（correctness），也就是能够互斥吗？答案是肯定的，因此自旋锁是一把正确的锁。
• 公平性（fairness）：显然自旋锁不提供任何的公平性保证，因此可能会导致饿死。
• 性能（performan）：单处理器上，性能开销相当大。因为在上锁后最少会自旋一个时间片，浪费 CPU 周期。在多处理器上，自旋锁性能不错。因为临界区一般很短，因此锁很快就可用了（自旋的时候），并没有浪费很多 CPU 周期，因此效果还不错。

硬件支持：比较并交换指令（CAS）

某些系统提供了另一个硬件原语——比较交换指令（SPARC 中是 compare-and-swap，x86 中是 compare-and-exchange）。下面是伪代码：

1
2
3
4
5
6

int CompareAndSwap(int *ptr, int expected, int new) {
    int actual = *ptr;
    if (actual == expected)
        *ptr = new;
    return actual;
}

可以看到和测试并设置指令的工作方式类似，但其实它十分强大，这在后面讨论「无等待同步（wait-free synchronization）时，会用到这条指令的强大之处。但如果只是用它实现一个简单的自旋锁，那么它无疑等价于上面分析的自旋锁。

链接的加载和条件式存储指令

一些平台提供了实现临界区的一对指令：链接的加载（load-lionked）和条件式存储（store-conditional）可以用来配合使用，实现其他并发结构。

1
2
3
4
5
6
7
8
9
10
11
12

int LoadLinked(int *ptr) {
    return *ptr;
}

int StoreConditional(int *ptr, int value) {
    if (no one has updated *ptr since the LoadLinked to this address) {
        *ptr = value;
        return 1; // success!
    } else {
        return 0; // failed to update
    }
}

条件式存储（store-conditional）指令，只有上一次执行LoadLinked的地址在期间都没有更新时， 才会成功，同时更新了该地址的值

先通过 LoadLinked 尝试获取锁值，如果判断到锁被释放了，就执行StoreConditional判断在「执行完」LoadLinked到StoreConditional「执行前」ptr 有没有被更新，没有被更新则说明没有其他线程来抢，可以进临界区，有更新则说明已经被其他线程抢走了，继续重复本段落所述内容循环：

1
2
3
4
5
6
7
8
9
10
11
12
13

void lock(lock_t *lock) {
    while (1) {
        while (LoadLinked(&lock->flag) == 1)
            ; // spin until it's zero
        if (StoreConditional(&lock->flag, 1) == 1)
            return; // if set-it-to-1 was a success: all done
                // otherwise: try it all over again
    }
}

void unlock(lock_t *lock) {
    lock->flag = 0;
}

硬件支持：获取并增加

获取并增加（fetch-and-add）指令能原子地返回特定地址的旧值，并且让该值自增一。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

int FetchAndAdd(int *ptr) {
    int old = *ptr;
    *ptr = old + 1;
    return old;
}
typedef struct lock_t {
    int ticket;
    int turn;
} lock_t;

void lock_init(lock_t *lock) {
    lock->ticket = 0;
    lock->turn = 0;
}

void lock(lock_t *lock) {
    // 开始挂号，获取当前号码。然后号码加1，保证每个人号码都不同
    int myturn = FetchAndAdd(&lock->ticket);
    // 等待被叫号
    while (lock->turn != myturn)
        ; // spin
}

void unlock(lock_t *lock) {
    // 只需要加1功能，不用返回旧值
    FetchAndAdd(&lock->turn);
}

这个方案使用了两个变量来构建锁（ticket和turn），基本操作也很简单：每次进入 lock，就获取当前ticket值，相当于挂号，然后全局 ticket 本身会自增一，因此后续线程都会获得属于自己的唯一 ticket值，lock->turn表示当前叫号值，叫到号的运行。unlock 时递增lock->turn更新叫号值就行（也就是叫下一个号）。这种返回式保证了公平性，相当于每个线程排队运行（FIFO）。

自旋过多：怎么办

一个线程会一直自旋检查一个不会改变的值，浪费掉整个时间片！如果有 N 个线程去竞争一个锁，情况会更糟糕。同样的场景下，会浪费 N−1 个时间片，只是自旋并等待一个线程释放该锁。

如何让锁不会不必要地自旋，浪费 CPU 时间？要解决这个问题，只有硬件支持是不够的，我们还需要操作系统的支持！

使用对列：休眠替代自旋

需要一个队列来保存等待锁的线程，上锁时发现锁已被持有，则入队并让调用线程休眠，解锁时从队列中取出一个线程唤醒。Solaris 中 park()能够让调用线程休眠，unpark(threadID)则会唤醒 threadID 标识的线程。

两阶段锁（two-phase lock）

两阶段锁中如果第一个自旋阶段没有获得锁，第二阶段调用者会睡眠，直到锁可用。Linux 中的 futex 就是这种锁，不过只自旋一次；更常见的方式是在循环中自旋固定的次数(希望这段时间内能获取到锁)，然后使用 futex 睡眠。

本章解答的关键问题：如何创建和控制线程？
操作系统应该提供那些创建和控制线程的接口？这些接口如何设计得好用又实用？

线程创建

1
2
3
4
5
6
7
8

#include <pthread.h>
int
pthread_create(
    pthread_t * thread,
    const pthread_attr_t * attr,
    void * (*start_routine)(void*),
    void * arg
);

上面的代码是 POSIX 中 创建线程的接口定义，该函数有 4 个参数，具体描述如下：

1. thread 是指向 pthread_t 结构体类型的指针，将利用这个结构来与该线程进行交互，因此需要将其传入 pthread_create() 以便初始化，相当于线程的唯一标识（身份证）
2. attr 是用于指定该线程可能具有的属性。比如栈的大小，或者线程调度优先级等信息。
3. *start_routine 是一个函数指针，指向要运行的函数
4. arg 要运行的函数的参数

线程完成

通过pthread_join阻塞等待线程完成

1
2
3
4
5

// 创建进程
pthread_t p;
pthread_create(&p, NULL, mythread, (void *) 100);、
// 等待进程完成
pthread_join(p, (void **) &m);

1. 第一个参数是 pthread_t 类型，用于指定要等待的线程
2. 第二个参数是一个指针，用于获取返回值。因为函数可以返回任何东西，所以它被定义为返回一个指向 void 的指针。

锁

除了创建和等待线程之外，POSIX 线程库提供的最有用的函数集，可能就是通过锁（lock）来提供互斥的那些函数了。最基本的一对函数是：

1
2

int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t *mutex);

使用的代码大概是这样子：

1
2
3
4
5

pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
// 或是int rc = pthread_mutex_init(&lock, NULL);
pthread_mutex_lock(&lock);
x = x + 1; // or whatever your critical section is
pthread_mutex_unlock(&lock);

注意锁必须正确初始化，上面的代码展示了两种上锁的方法（使用 PTHREAD_MUTEX_INITIALIZER 常量或者使用 pthread_mutex_init() 函数，一般情况下更推荐用第二种。

条件变量（condition variable）

所有线程库还有一个主要组件，就是条件变量。当线程之间必须发生某种信号时，条件变量就很有用。比如一个线程在等待另一个线程继续执行某些操作。

1
2

int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);
int pthread_cond_signal(pthread_cond_t *cond);

要使用条件变量，必须另外有一个与此条件相关的锁。在调用上述任何一个函数时，应该持有这个锁。

第一个函数pthread_cond_wait()使调用线程进入休眠状态，因此等待其他线程发出信号，通常当程序中的某些内容发生变化时，现在正在休眠的线程可能会关心它。典型的用法如下所示：

1
2
3
4
5
6

pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
pthread_mutex_lock(&lock);
while (ready == 0)
    pthread_cond_wait(&cond, &lock);
pthread_mutex_unlock(&lock);

唤醒线程的代码运行在另外某个线程中，调用pthread_cond_signal时也需要持有对应锁。像下面这样：

1
2
3
4

pthread_mutex_lock(&lock);
ready = 1;
pthread_cond_signal(&cond);
pthread_mutex_unlock(&lock);

pthread_cond_wait有第二个参数，因为它会隐式地释放锁，以便在其线程休眠后唤醒线程可以获取锁，之后又会重新获得锁。
本例通过 while 判断 ready 的值的变更，而不是通过条件变量唤醒判断 ready 已变更。将唤醒视为某种事物可能已经发生变化的暗示，而不是绝对的事实，这样更安全

编译和运行

代码需要包括头文件 pthread.h 才能编译。链接时需要 pthread 库，增加 -pthread 标记。

1

prompt> gcc -o main main.c -Wall -pthread

小结

本章介绍了基本的 pthread 库，包括线程创建、锁实现互斥执行、通过条件变量的信号和等待。如需更多信息，请在 Linux 系统上输入 man -k pthread 来获取。

当你使用 POSIX 线程库（或者实际上，任何线程库）来构建多线程程序时，需要记住一些小而重 要的事情：

• 保持简洁。最重要的一点，线程之间的锁和信号的代码应该尽可能简洁。复杂的线程交互容易产生缺陷。
• 让线程交互减到最少。尽量减少线程之间的交互。每次交互都应该想清楚，并用验证过的、正确的方法来实现（很多方法会在后续章节中学习）。
• 初始化锁和条件变量。未初始化的代码有时工作正常，有时失败，会产生奇怪的结果。
• 检查返回值。当然，任何 C 和 UNIX 的程序，都应该检查返回值，这里也是一样。否则会导致古怪而难以理解的行为，让你尖叫，或者痛苦地揪自己的头发。
• 注意传给线程的参数和返回值。具体来说，如果传递在栈上分配的变量的引用，可能就是在犯错误。
• 每个线程都有自己的栈。类似于上一条，记住每一个线程都有自己的栈。因此，线程局部变量应该是线程私有的，其他线程不应该访问。线程之间共享数据，值要在堆（heap）或者其他全局可访问的位置。
• 线程之间总是通过条件变量发送信号。切记不要用标记变量来同步。
• 多查手册。尤其是 Linux 的 pthread 手册，有更多的细节、更丰富的内容。请仔细阅读！

OSTEP 的第二部分将介绍并发相关的内容，因此本章将首先介绍为单个运行进程提供的新抽象：进程（thread）。经典的观点是一个程序只有一个执行点（一个程序计数器，用来存放要执行的指令），但多线程（multi- threaded）程序会有多个执行点（也就是多个程序计数器，每个都用于取指令与执行）。换个角度来看，每个线程类似于独立的进程，只有一点区别：它们共享地址空间，从而能够访问相同的数据。

线程的结构

单个线程的状态与进程状态非常类似。线程有一个程序计数器（Program Counter），记录程序从哪里获取指令。每个线程有自己的一组用于计算的寄存器。所以，如果有两个线程运行在一个处理器上，从运行一个线程（T1）切换到另一个线程（T2）时，必定发生上下文切换（context switch）。线程之间的上下文切换类似于进程间的上下文切换。对于进程，我们将状态保存到进程控制块（Process Control Block，PCB）。现在，我们需要一个或多个线程控制块（Thread Control Block，TCB），保存每个线程的状态。但是，与进程相比，线程之间的上下文切换有一点主要区别：地址空间保持不变（即不需要切换当前使用的页表）。

线程和进程之间另一个主要的区别在于栈。在传统的进程内存模型中，只有一个栈，通常位于地址空间的底部。而多线程的进程中，每个线程独立运行，因此地址空间中不只有一个栈，而是每个线程都有一个栈。如下图所示：

实例：进程创建

下面代码演示了一个简单的多线程程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#include <stdio.h>
#include <assert.h>
#include <pthread.h>

void *mythread(void *arg) {
    printf("%s\n", (char *) arg);
    return NULL;
}

int
main(int argc, char *argv[]) {
    pthread_t p1, p2;
    int rc;
    printf("main: begin\n");
    rc = pthread_create(&p1, NULL, mythread, "A"); assert(rc == 0);
    rc = pthread_create(&p2, NULL, mythread, "B"); assert(rc == 0);
    // join waits for the threads to finish
    rc = pthread_join(p1, NULL); assert(rc == 0);
    rc = pthread_join(p2, NULL); assert(rc == 0);
    printf("main: end\n");
    return 0;
}

这个代码中，主程序创建了两个线程，分别执行 mythread() 函数，但传参不一样。一旦线程创建，可能会立即运行或者处于就绪状态等待执行（这取决于调度程序）。下面三个表格中分别列举了几种可能的运行顺序：

情况一：

情况二：

情况三：

不难看出线程使得编程变得复杂：已经很难说出什么时候会运行了！

为什么更糟糕：共享数据

两个线程递增同一个数，每次运行最终结果都不一样？原因是共享数据未保证操作原子性 ，因为代码中看似一行代码的「加加」，在真实执行时是由几个指令完成的，因此存在并发问题。

fork() 系统调用

在执行函数 fork()时，创建了一个子进程，此时是两个进程同时运行，fork 出来的进程称为「子进程」

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
    printf("hello world (pid:%d)\n", (int)getpid());
    int rc = fork();
    if (rc < 0)
    { // fork failed; exit
        fprintf(stderr, "fork failed\n");
        exit(1);
    }
    else if (rc == 0)
    { // child (new process)
        printf("hello, I am child (pid:%d)\n", (int)getpid());
    }
    else
    { // parent goes down this path (main)
        printf("hello, I am parent of %d (pid:%d)\n",
               rc, (int)getpid());
    }
    return 0;
}

输出如下：

1
2
3
4

prompt> ./p1
hello world (pid:29146)
hello, I am parent of 29147 (pid:29146)
hello, I am child (pid:29147)

上面这段程序执行了一次 fork 操作，fork()函数是一个神奇的操作，它只被调用了一次，却产生了两个返回值。对于父进程来说，其返回值是子进程的 pid；对于子进程来说，其返回值为 0。

子进程并不是完全拷贝了父进程，所以子进程不会从 main 开始执行，该程序的首行打印并未被子进程执行。它拥有自己的「地址空间」（即拥有自己的私有内存）、寄存器、程序计数器等。

当然，父进程与子进程的执行顺序并不是绝对的，这都取决于调度器怎么调度，子进程也可能比父进程先执行完。

wait() 系统调用

wait()函数用于使父进程（也就是调用 wait()的进程）阻塞，直到一个子进程结束或者该进程接收到了一个指定的信号为止。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int main(int argc, char *argv[])
{
    printf("hello world (pid:%d)\n", (int)getpid());
    int rc = fork();
    if (rc < 0)
    { // fork failed; exit
        fprintf(stderr, "fork failed\n");
        exit(1);
    }
    else if (rc == 0)
    { // child (new process)
        printf("hello, I am child (pid:%d)\n", (int)getpid());
    }
    else
    { // parent goes down this path (main)
        int wc = wait(NULL);
        printf("hello, I am parent of %d (wc:%d) (pid:%d)\n",
               rc, wc, (int)getpid());
    }
    return 0;
}

1
2
3
4

prompt> ./p2
hello world (pid:29266)
hello, I am child (pid:29267)
hello, I am parent of 29267 (wc:29267) (pid:29266)

这里因为父进程调用了wait()方法，因此子进程会先于父进程执行完毕。如果父进程先执行时，会等待子进程结束，才会继续执行。

exec() 系统调用

exec()这个系统调用可以让子进程执行与父进程不同的程序

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/wait.h>

int main(int argc, char *argv[])
{
    printf("hello world (pid:%d)\n", (int)getpid());
    int rc = fork();
    if (rc < 0)
    { // fork failed; exit
        fprintf(stderr, "fork failed\n");
        exit(1);
    }
    else if (rc == 0)
    { // child (new process)
        printf("hello, I am child (pid:%d)\n", (int)getpid());
        char *myargs[3];
        myargs[0] = strdup("wc");   // program: "wc" (word count)
        myargs[1] = strdup("p3.c"); // argument: file to count
        myargs[2] = NULL;           // marks end of array
        execvp(myargs[0], myargs);  // runs word count
        printf("this shouldn't print out");
    }
    else
    { // parent goes down this path (main)
        int wc = wait(NULL);
        printf("hello, I am parent of %d (wc:%d) (pid:%d)\n",
               rc, wc, (int)getpid());
    }
    return 0;
}

1
2
3
4
5

prompt> ./p3
hello world (pid:29383)
hello, I am child (pid:29384)
 29 107 1030 p3.c
hello, I am parent of 29384 (wc:29384) (pid:29383)

在这个例子中，子进程调用 execvp()来运行字符计数程序 wc。实际上，它针对源代码文件 p3.c 运行 wc，从而告诉我们该文件有多少行、多少单词，以及多少字节。

给定可执行程序的名称（如 wc）及需要的参数（如 p3.c）后，exec()会从可执行程序中加载代码和静态数据，并用它「覆写」自己的代码段（以及静态数据），堆、栈及其他内存空间也会被重新初始化。然后操作系统就执行该程序，将参数通过 argv 传递给该进程。因此，它并没有创建新进程，而是直接将当前运行的程序（以前的 p3）替换为不同的运行程序（wc）。子进程执行 exec()之后，几乎就像 p3.c 从未运行过一样。对 exec()的成功调用永远不会返回。如果 exec 函数执行失败, 它会返回失败的信息, 而且进程继续执行后面的代码。

此时子进程的 pid 号并没有变，且还是该父进程的子进程，所以并不会影响 wait()操作，等待该进程的操作（统计字节）完成后，wait()才会返回，父进程同时退出阻塞状态

为什么这么设计 API

事实证明，这种分离 fork()及 exec()的做法在构建 UNIX shell 的时候非常有用，因为这给了 shell 在 fork 之后 exec 之前运行代码的机会，这些代码可以在运行新程序前改变环境，从而让一系列有趣的功能很容易实现。

shell 也是一个用户程序，它首先显示一个提示符（prompt），然后等待用户输入。你可以向它输入一个命令（一个可执行程序的名称及需要的参数），大多数情况下，shell 可以在文件系统中找到这个可执行程序，调用 fork()创建新进程，并调用 exec()的某个变体来执行这个可执行程序，调用 wait()等待该命令完成。子进程执行结束后，shell 从 wait()返回并再次输出一个提示符，等待用户输入下一条命令。

fork()和 exec()的分离，让 shell 可以方便地实现很多有用的功能。比如：

1

prompt> wc p3.c > newfile.txt

在上面的例子中，wc 的输出结果被重定向（redirect）到文件 newfile.txt 中（通过 newfile.txt 之前的大于号来指明重定向）。shell 实现结果重定向的方式也很简单，当完成子进程的创建后，shell 在调用 exec()之前先关闭了标准输出（standard output），打开了文件 newfile.txt。这样，即将运行的程序 wc 的输出结果就被发送到该文件，而不是打印在屏幕上。

下面我们来简单看一下重定向的工作原理，是基于对操作系统管理文件描述符方式的假设，首先看代码实例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <sys/wait.h>

int main(int argc, char *argv[])
{
    int rc = fork();
    if (rc < 0)
    { // fork failed; exit
        fprintf(stderr, "fork failed\n");
        exit(1);
    }
    else if (rc == 0)
    { // child: redirect standard output to a file
        close(STDOUT_FILENO);
        open("./p4.output", O_CREAT | O_WRONLY | O_TRUNC, S_IRWXU);

        // now exec "wc"...
        char *myargs[3];
        myargs[0] = strdup("wc");   // program: "wc" (word count)
        myargs[1] = strdup("p4.c"); // argument: file to count
        myargs[2] = NULL;           // marks end of array
        execvp(myargs[0], myargs);  // runs word count
    }
    else
    { // parent goes down this path (main)
        int wc = wait(NULL);
    }
    return 0;
}

要看懂上面的例子，首先要补充点Unix文件描述符的知识:

• 每个 Unix 进程（除了可能的守护进程）应均有三个标准的 POSIX 文件描述符，对应于三个标准流：

• UNIX 系统从 0 开始寻找可以使用的文件描述符，进程启动后默认打开了标准输出STDOUT_FILENO输出到屏幕，此时所有的对标准输出文件描述符的输出，如 printf()，都会打印的屏幕上：

1
2

root@hjk:~/repo/os_test# ./a.out
33 113 864 p4.c

• 如果使用_close(STDOUT_FILENO)_关闭了这个描述符，再去调用printf()，系统会提示找不到文件描述符

1
2

root@hjk:~/repo/os_test# ./a.out
wc: write error: Bad file descriptor

• 此时再打开新的文件描述符，会将所有的对标准输出文件描述符的输出定向到该文件描述符上（因为上面把「标准输出」关闭了，并且 unix 是从 0 开始查找可用的文件描述符的，0已经被使用了，因此会绑定到 1 上）

1

open("./p4.output", O_CREAT | O_WRONLY | O_TRUNC, S_IRWXU)

扩展阅读：管道

UNIX管道也是用类似的方式实现的，但用的是 pipe()系统调用。在这种情况下，一个进程的输出被链接到了一个内核管道（pipe）上（队列），另一个进程的输入也被连接到了同一个管道上。因此，前一个进程的输出无缝地作为后一个进程的输入，许多命令可以用这种方式串联在一起，共同完成某项任务。比如通过将 grep、wc 命令用管道连接可以完成从一个文件中查找某个词，并统计其出现次数的功能：

作业

TODO，目前在读第一遍，先粗读一遍，第二遍再精读与完成课后习题

我们在使用计算机的过程中，通常都会运行多个程序。比如：同时运行浏览器、播放器、游戏等等。除了这些我们熟知的程序外，系统内部还运行着上百个程序。现代的处理器一般都有多个核（注意，这里的核其实是指一个「运算单元」也就是一个 CPU，也就是说我们平时购买的一个物理的 CPU 里面，一般是有多个 CPU 的）。如果每个程序都独占一个CPU，那么就可能需要上百个「运算单元」，那么这样的 CPU 也太过昂贵了。

这也是操作系统需要解决的问题：「如何提供有许多CPU的假象」。操作系统通过虚拟化（virtualizing）CPU 来提供这种假象。通过让一个进程只运行一个时间片，然后切换到其他进程，操作系统就提供了存在许多 CPU 的假象了。通俗的来讲就是通过超快速的切换进程，从而达到让用户看起来每个进程都在同时运行。

进程 API

• 创建（Create）：用于创建新进程的方法。比如 shell 中键入命令或者在桌面双击应用图标时，就会调用操作系统来创建新的进程，运行指定的程序。
• 销毁（destroy）：有创建的接口那当然还需要销毁的接口，因此系统还提供强制销毁进程的接口，确保用户可以随时的终止它们。虽然进程运行完成后正常会自动退出，但也可能会因为意外的操作导致它不退出，因此该接口也是一个兜底的操作。
• 等待（wait）：等待进程停止运行。
• 状态（status）：获取有关进程的状态信息。例如运行了多长时间、当前处于什么状态等。
• 其他控制（miscellaneous control）：除了上面的操作外，有时还可能有其他控制，比如大多数操作系统提供某种方法来暂停进程（停止运行一段时间）。

进程创建

首先看一下一个程序是如何转换为进程的。具体来说是操作系统是如何启动并运行一个程序的？

操作系统运行程序必须做的第一件事是将代码和所有静态数据（例如初始化变量）加载（load）到内存中，加载到进程的地址空间中。简单的来说就是从持久化存储的「磁盘」导入到易失的「内存」中。（如下图所示）

在早起的操作系统中，加载的这个过程是尽早（eagerly）完成，即在运行程序之前全部完成。现代操作系统则是惰性（lazily）执行该过程，即仅在程序运行期间按需加载代码或数据片段。这个过程涉及到内存虚拟化，后面的对应章节会展开具体讲解。

加载到内存后操作系统在运行之前还会执行其他一些操作，比如为程序运行时的栈（run-time stack 或 stack）、堆（heap）、局部变量等分配一些内存。此外还会执行一些其他初始化任务，特别是输入输出（I/O）相关的任务，例如：stdin、stdout、stderr等等。最后会跳转到程序的入口，也就是 main() 函数，至此 OS 会将 CPU 的控制权转交到新创建的进程中，程序开始运行。

为此进程的创建过程总结如下：

1. 加载数据到内存
2. 为栈分配空间
3. 为堆分配空间
4. I/O初始化
5. 运行程序入口（main 函数）

进程状态

进程的三种状态：

• 运行（running）：运行状态表示它正在执行指令，意味着进程正在处理器上运行。
• 就绪（ready）：该状态表示程序已经准备好运行了，只是操作系统还未选择该进程运行
• 阻塞（blocked）：在阻塞状态下，一个进程执行了某种操作，直到发生其他事件时才会准备运行。常见的例子是，当进程向磁盘发起 I/O 请求时，它会被阻塞，因此其他进程可以在这时候使用处理器，提高处理器的使用率。

上图展示了上述三种状态之间的转换关系，可以根据操作系统的载量，让进程在就绪状态和运行状态之间转换。从就绪 -> 运行意味着该进程已经被调度（scheduled）。从运行 -> 就绪意味着该进程已经取消调度（descheduled）。一旦进程被阻塞（例如，通过发起 I/O 操作），OS 将保持进程的这种状态，直到发生某种事件（例如，I/O 完成）。此时，进程再次转入就绪状态（也可能立即再次运行，如果操作系统这样决定）。

关于调度的策略，简单总结下，就是一个进程阻塞或停止时，就会去调度另一个就绪的进程，让 CPU 一直保持在满负荷状态，从而提高 CPU 的使用率。

数据结构

为了跟踪每个进程的状态，操作系统可能会为所有就绪的进程保留某种进程列表（process list），以及跟踪当前正在运行的进程的一些附加信息。操作系统还必须以某种方式跟踪被阻塞的进程。当 I/O 事件完成时，操作系统应确保唤醒正确的进程，让它准备好再次运行。

那么既然操作系统也是个程序，并且是由C语言编写的，因此我们可以来看看进程在代码中的数据结构是啥样的，这无疑有利于我们对进程的理解：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

// the registers xv6 will save and restore
// to stop and subsequently restart a process
struct context
{
    int eip;
    int esp;
    int ebx;
    int ecx;
    int edx;
    int esi;
    int edi;
    int ebp;
};
// the different states a process can be in
// 可以看到实际操作系统对于进程状态的定义远不止上面介绍的3种
enum proc_state
{
    UNUSED,
    EMBRYO,
    SLEEPING,
    RUNNABLE,
    RUNNING,
    ZOMBIE
};
// the information xv6 tracks about each process
// including its register context and state
struct proc
{
    char *mem;    // Start of process memory
    uint sz;      // Size of process memory
    char *kstack; // Bottom of kernel stack
    // for this process
    enum proc_state state;      // Process state
    int pid;                    // Process ID
    struct proc *parent;        // Parent process
    void *chan;                 // If non-zero, sleeping on chan
    int killed;                 // If non-zero, have been killed
    struct file *ofile[NOFILE]; // Open files
    struct inode *cwd;          // Current directory
    struct context context;     // Switch here to run process
    struct trapframe *tf;       // Trap frame for the
                                // current interrupt
};

该数据结构展示了 xv6 内核中每个进程的相关信息类型。这里用到 XV6 内核是因为它足够简单，是上手操作系统的一个不错选择 。 并且在“真正的”操作系统中存在类似的进程结构，如 Linux、macOS X 或 Windows。

除了运行、就绪和阻塞之外，还有其他一些进程可以处于的状态：

• 初始（initial）状态

  有时候系统会有一个初始（initial）状态，表示进程在创建时处于的状态。

• 最终（final）状态

  另外，一个进程可以处于已退出但尚未清理的最终（final）状态（在基于 UNIX 的系统中，这称为僵尸状态）。这个最终状态非常有用，因为它允许其他进程（通常是创建进程的父进程）检查进程的返回代码，并查看刚刚完成的进程是否成功执行（通常，在基于 UNIX 的系统中，程序成功完成任务时返回零，否则返回非零）。完成后，父进程将进行最后一次调用（例如，wait()），以等待子进程的完成，并告诉操作系统它可以清理这个正在结束的进程的所有相关数据结构

作业

关于作业，本文只摘取部分我认为比较重要的部分：立即处理阻塞完成的进程是否是一个好主意?（也就是第六题）

• 第六题：在本题中，进程 0 首先进入 IO，此时由于-S SWITCH_ON_IO参数，进程 0 进入阻塞状态，cpu 被切换到运行进程 1，当进程 0 的 IO 完成后，进程 1 继续执行，直到完成。也就是 IO 完成事件不会被立即处理，由于进程 0 的 IO 动作较为频繁，会使它长时间处于 IO 完成等待状态，导致后续的 IO 操作时 cpu 已经无事可做了，在本例条件下降低了效率，输出如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

$ python3 ./process-run.py -l 3:0,5:100,5:100,5:100 -S SWITCH_ON_IO -I IO_RUN_LATER -c -p
Time        PID: 0        PID: 1        PID: 2        PID: 3           CPU           IOs
  1         RUN:io         READY         READY         READY             1          
  2        BLOCKED       RUN:cpu         READY         READY             1             1
  3        BLOCKED       RUN:cpu         READY         READY             1             1
  4        BLOCKED       RUN:cpu         READY         READY             1             1
  5        BLOCKED       RUN:cpu         READY         READY             1             1
  6        BLOCKED       RUN:cpu         READY         READY             1             1
  7*         READY          DONE       RUN:cpu         READY             1          
  8          READY          DONE       RUN:cpu         READY             1          
  9          READY          DONE       RUN:cpu         READY             1          
 10          READY          DONE       RUN:cpu         READY             1          
 11          READY          DONE       RUN:cpu         READY             1          
 12          READY          DONE          DONE       RUN:cpu             1          
 13          READY          DONE          DONE       RUN:cpu             1          
 14          READY          DONE          DONE       RUN:cpu             1          
 15          READY          DONE          DONE       RUN:cpu             1          
 16          READY          DONE          DONE       RUN:cpu             1          
 17    RUN:io_done          DONE          DONE          DONE             1          
 18         RUN:io          DONE          DONE          DONE             1          
 19        BLOCKED          DONE          DONE          DONE                           1
 20        BLOCKED          DONE          DONE          DONE                           1
 21        BLOCKED          DONE          DONE          DONE                           1
 22        BLOCKED          DONE          DONE          DONE                           1
 23        BLOCKED          DONE          DONE          DONE                           1
 24*   RUN:io_done          DONE          DONE          DONE             1          
 25         RUN:io          DONE          DONE          DONE             1          
 26        BLOCKED          DONE          DONE          DONE                           1
 27        BLOCKED          DONE          DONE          DONE                           1
 28        BLOCKED          DONE          DONE          DONE                           1
 29        BLOCKED          DONE          DONE          DONE                           1
 30        BLOCKED          DONE          DONE          DONE                           1
 31*   RUN:io_done          DONE          DONE          DONE             1          

Stats: Total Time 31
Stats: CPU Busy 21 (67.74%)
Stats: IO Busy  15 (48.39%)

• 为什么运行一个刚刚完成 I/O 的进程会是一个好主意? 对于 IO 频繁的应用来说，立即运行和不立即运行会有这么两种情况：
  • 立即运行：因为该进程是一个 IO 频繁的应用，因此立即执行后可以立马的进行下一个 IO 操作，进入阻塞态，让出 CPU 的同时等待下一个 IO 事件。
  • 不立即运行：在上一个 IO 完成后，CPU 调度前的时间将会被白白浪费，因为该进程是一个 IO 频繁的。输出如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

$ python3 ./process-run.py -l 3:0,5:100,5:100,5:100 -S SWITCH_ON_IO -I IO_RUN_IMMEDIATE -c -p
Time        PID: 0        PID: 1        PID: 2        PID: 3           CPU           IOs
  1         RUN:io         READY         READY         READY             1          
  2        BLOCKED       RUN:cpu         READY         READY             1             1
  3        BLOCKED       RUN:cpu         READY         READY             1             1
  4        BLOCKED       RUN:cpu         READY         READY             1             1
  5        BLOCKED       RUN:cpu         READY         READY             1             1
  6        BLOCKED       RUN:cpu         READY         READY             1             1
  7*   RUN:io_done          DONE         READY         READY             1          
  8         RUN:io          DONE         READY         READY             1          
  9        BLOCKED          DONE       RUN:cpu         READY             1             1
 10        BLOCKED          DONE       RUN:cpu         READY             1             1
 11        BLOCKED          DONE       RUN:cpu         READY             1             1
 12        BLOCKED          DONE       RUN:cpu         READY             1             1
 13        BLOCKED          DONE       RUN:cpu         READY             1             1
 14*   RUN:io_done          DONE          DONE         READY             1          
 15         RUN:io          DONE          DONE         READY             1          
 16        BLOCKED          DONE          DONE       RUN:cpu             1             1
 17        BLOCKED          DONE          DONE       RUN:cpu             1             1
 18        BLOCKED          DONE          DONE       RUN:cpu             1             1
 19        BLOCKED          DONE          DONE       RUN:cpu             1             1
 20        BLOCKED          DONE          DONE       RUN:cpu             1             1
 21*   RUN:io_done          DONE          DONE          DONE             1          

Stats: Total Time 21
Stats: CPU Busy 21 (100.00%)
Stats: IO Busy  15 (71.43%)

本系列文章将按照笔者阅读章节顺序编写，结合原文与自己的感悟，以作笔记之用，如有不足之处，恳请在评论区指出

操作系统主要的三个部分分别是：虚拟化（virtualization）、并发（concurrency）和持久化（persistence），这是本书主要学习的3个关键概念。通过学习这三个概念来理解操作系统这门课程。

国内许多教材/八股文对操作系统的描述可能与本书差异较大，但我个人感觉其实都是描述一个东西，相比之下教材上只是描述的更具体。比如进程/线程其实是操作系统实现虚拟化的其中一个手段的等等。

虚拟化

CPU 虚拟化

下面是一个简单的程序，它所做的只是循环每秒打印出用户在命令行中传入的字符串：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#include <stdio.h>
#include <stdlib.h>
#include <time.h>  
#include <assert.h>
#include "common.h"

int main(int argc, char const *argv[])
{
    if (argc != 2) {
        fprintf(stderr, "usage: cpu <string>\n");
        exit(1);
    }
    char *str = argv[1];
    while (1)
    {
        Spin(1);
        printf("%s\n", str);
    }
    

    return 0;
}

common.h 头文件将放在本文末尾，当然你也可以访问官网/GitHub来获取

当我们在一个单处理器（cpu）的系统上编译并运行它，我们将看到以下内容：

1
2
3
4
5
6
7
8

farmer:~/studys/operating-systems/ch02$ ./cpu A
A
A
A
A
A
^C
farmer:~/studys/operating-systems/ch02$

这个结果看起来十分合理不是吗？现在让我们运行同一个程序的不同实例，来看看结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

farmer:~/studys/operating-systems/ch02$ ./cpu A & ./cpu B & ./cpu C &
[1] 208278
[2] 208279
[3] 208280
B
C
A
B
C
C
B
A
B
A
C
B
A
C
...

现在事情开始有趣起来了，尽管只有一个处理器，但是这几个程序在我们用户的视角看来还是在同时运行的，看起来就像有多个处理器在同时执行这3个程序一样！

而这种将单个CPU（或其中一小部分）转换成看似多个CPU，从而让许多程序看似同时运行的技术，这就是所谓的虚拟化CPU（virtualizing the CPU）

内存虚拟化

看完了CPU让我们来看看内存，现代机器提供的物理内存（physical memory）模型其实非常的简单，就是一个字节数组而已。程序通过指定一个地址（address）来访问、写入或更新存在那里的数据。

程序运行时一直要访问内存，程序将所有数据结构保存在内存中，并通过各种指令来访问它们，因此每次读取指令都会访问内存。下面来看一个简单的demo：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include "common.h"

int main(int argc, char const *argv[])
{
    int *p = malloc(sizeof(int)); //a1
    assert(p != NULL);
    printf("(%d) memory address of p: %08x\n", getpid(), (unsigned) p); //a2

    *p = 0; //a3
    while (1)
    {
        Spin(1);
        *p = *p + 1;
        printf("(%d) p: %d\n", getpid(), *p); // a4
    }

    return 0;
}

该程序的输出如下：

1
2
3
4
5
6
7
8

farmer:~/studys/operating-systems/ch02$ ./mem 
(208544) memory address of p: 18afa2a0
(208544) p: 1
(208544) p: 2
(208544) p: 3
(208544) p: 4
(208544) p: 5
^C

这个demo首先为 p 这个变量分配了一些内存（a1行）。然后打印出内存的地址（a2），然后将数字0放入新分配的内存（a3）的第一个空位中。最后程序循环，延迟一秒钟并递增 p 中保存的地址值。在每个打印语句中，它还会打印出正在运行程序的进程标识符（PID）。

同样的，我们再次运行多个实例来看看会发生什么：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

farmer:~/studys/operating-systems/ch02$ ./mem & ./mem &
[1] 24113
[2] 24114
(24113) memory address of p: 00200000
(24114) memory address of p: 00200000
(24113) p: 1
(24114) p: 1
(24114) p: 2
(24113) p: 2
(24113) p: 3
(24114) p: 3
(24113) p: 4
(24114) p: 4
...

我们可以看到每个实例都在相同的地址（00200000）分配了内存，但每个似乎都独立更新了00200000处的值！就好像每个正在运行的程序都有自己的私有地址，而不是与其他正在运行的程序共享相同的物理内存。

而这真是操作系统虚拟化内存（virtualizing memory）时发生的情况，每个进程访问自己的私有虚拟地址空间（virtual address space）（有时称为地址空间，address space），操作系统以某种方式映射到机器的物理内存上，让正在运行的实例完全拥有自己的物理内存。

但实际情况是，物理内存是由操作系统管理的共享资源。而这也正是上文提到的「虚拟化」的内容。

并发

并发是这本书的第二个部分，并发只是一个用来代指「同时处理很多事情」所带来一系列问题的代词，而这些问题是在同时（并发）处理很多事情时出现且必须解决的。

那么为什么并发通常出现在《操作系统》这门课中呢？其实是因为并发问题首先出现在操作系统中，而随着软件工程的发展，现代多线程（multi-threaded）程序也存在相同的问题。我们来看一个具体的多线程例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

#include <stdio.h>
#include <stdlib.h>
#include "common.h"
#include "common_threads.h"

volatile int counter = 0;
int loops;

void *worker(void *arg) {
    int i;
    for ( i = 0; i < loops; i++)
    {
        counter++;
    }
    return NULL;
}

int main(int argc, char *argv[]) {
    if (argc != 2) { 
fprintf(stderr, "usage: threads <loops>\n"); 
exit(1); 
    } 
    loops = atoi(argv[1]);
    pthread_t p1, p2;
    printf("Initial value : %d\n", counter);
    Pthread_create(&p1, NULL, worker, NULL); 
    Pthread_create(&p2, NULL, worker, NULL);
    Pthread_join(p1, NULL);
    Pthread_join(p2, NULL);
    printf("Final value   : %d\n", counter);
    return 0;
}

这个例子中利用Pthread_create()创建了两个线程（thread），每个线程开始在一个名为worker()的函数中运行，该函数中只是递增一个计数器，循环 loops 次。

下面是将变量loops的输入值设置为 1000 时的输出结果，根据代码我们可以很容易的猜到运行结果是 2000，因为每个线程会循环 1000 次并对计数器做一个累加的操作。也就是说当输入为 N 时，直观的预计结果为 2N：

1
2
3

farmer:~/studys/operating-systems/ch02$ ./thread 1000
Initial value : 0
Final value   : 2000

但如果对并发编程有点了解的话会发现这段代码中存在一个问题：计数器累加操作并非原子方式（atomically）的。让我们运行相同的程序，但 loops 的值更高，然后看看会发生什么：

1
2
3
4
5
6
7
8
9

farmer:~/studys/operating-systems/ch02$ ./thread 100000
Initial value : 0
Final value   : 100000
farmer:~/studys/operating-systems/ch02$ ./thread 100000
Initial value : 0
Final value   : 105018
farmer:~/studys/operating-systems/ch02$ ./thread 100000
Initial value : 0
Final value   : 135669

事实证明当我们将 loops 值设置的更高后，得到的最终值不是 200000。并且其最终值在每次运行中都是不一样的结果！

这些奇怪的，不合常理的结果与指令如何执行有关。上面程序中的关键部分是增加共享计数器（counter）的地方，它需要 3 条指令：一是将计数器的值翀内存中加载到寄存器，二是将其做递增操作，三是将其保存回内存。因为这三条指令并不是以原子的方式执行（所有的指令一次性执行）的，所以才会导致这些奇怪的事情发生。而这种问题通常叫：并发（concurrency）问题

持久性

我们都知道程序是运行在内存中的，如果发生断电或系统崩溃等情况，那么内存中的数据是容易丢失的。因为像 DRAM 这样的设备以易失（volatile）的方式存储数据，因此我们需要硬件和软件来持久化（persistently）的存储数据。这样的存储对于所有系统来说都十分重要，因为数据是无价的。

操作系统中管理硬盘的软件通常称为文件系统（file system）。因此它负责以可靠和高效的方式，将用户创建的任何文件（file）存储在系统的磁盘上。而不像 CPU 和内存一样需要操作系统提虚拟化，因为它是可以被多个程序所共有的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#include <stdio.h>
#include <unistd.h>
#include <assert.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <string.h>

int main(int argc, char *argv[]) {
    int fd = open("/tmp/file", O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
    assert(fd >= 0);
    char buffer[20];
    sprintf(buffer, "hello world\n");
    int rc = write(fd, buffer, strlen(buffer));
    assert(rc == (strlen(buffer)));
    fsync(fd);
    close(fd);
    return 0;
}

上面的程序向操作系统发出了 3 个调用。一是 open() 调用，用来创建并打开一个文件。第二个是 write() 调用，将一些数据(「hello world\n」这串字符) 写入文件。第三则是 close() 调用来关闭文件，从而表明程序不会再向该文件写入更多的数据。

而上面提到的这些系统调用（system call）会被转到称为文件系统的操作系统部分，然后由文件系统处理这些请求，并向用户返回某种代码来表示结果。

首先确定新数据将驻留在磁盘上的哪个位置，然后在文件系统所维护的各种结构中对其进行记录。这样做需要向底层存储设备发出 I/O 请求，以读取现有结构或更新（写入）它们。所有写过设备驱动程序（device driver）的人都知道，让设备现表你执行某项操作是一个复杂而详细的过程。它需要深入了解低级别设备接口及其确切的语义。幸运的是，操作系统提供了一种通过系统调用来访问设备的标准和简单的方法。因此，OS 有时被视为标准库（standard library）。

出于性能方面的原因，大多数文件系统首先会延迟这些写操作一段时间，希望将其批量分组为较大的组。为了处理写入期间系统崩溃的问题，大多数文件系统都包含某种复杂的写入协议，如日志（journaling）或写时复制（copy-on-write），仔细排序写入磁盘的操作，以确保如果在写入序列期间发生故障，系统可以在之后恢复到合理的状态。为了使不同的通用操作更高效，文件系统采用了许多不同的数据结构和访问方法，从简单的列表到复杂的 B 树。

设计目标

设计目标指的是「开发和设计操作系统时所设定的主要目标和原则」，或者说是操作系统的一些基本设计原则。

1. 一个最基本的目标，是建立一些抽象（abstraction），让系统方便和易于使用。抽象对我们在计算机科学中做的每件事都很有帮助。抽象使得编写一个大型程序成为可能，将其划分为小而且容易理解的部分
2. 设计和实现操作系统的第二个目标，是提供高性能（performance）。换言之，我们的目标是最小化操作系统的开销（minimize the overhead）。但是虚拟化的设计是为了易于使用，无形之中会增大开销，比如虚拟页的切换，cpu 的调度等等，所以尽可能的保持易用性与性能的平衡至关重要
3. 在应用程序之间以及在 OS 和应用程序之间提供保护（protection）。因为我们希望让许多程序同时运行，所以要确保一个程序的恶意或偶然的不良行为不会损害其他程序。保护是操作系统基本原理之一的核心，这就是隔离（isolation）。让进程彼此隔离是保护的关键，因此决定了 OS 必须执行的大部分任务
4. 操作系统往往力求提供高度的可靠性（reliability）。因为操作系统必须不间断运行，当它失效时，系统上运行的所有应用程序也会失效。

总结

本章节主要用于对操作系统全貌的一个介绍，回答了：“操作系统是什么” 的问题。

Reference

• 《Operating Systems: Three Easy Pieces》中文版

一行记录的存储格式

我们执行 SQl 的时候，查询的结果是一行行的格式返回的.因此在讲解索引、数据页前我们先来看一下 MySQL 中一行记录是怎么存储的：

在上图中我们可以看到,一条完整的记录分为「记录头」与「真实数据」两部份，下面展开看看记录头的部份：

1. 记录头信息
我们知道 MySQL 支持一些变长的数据类型与NULL值，比如 TEXT、VARCHAR 等等。这些类型的字段存储多少字节的数据是不固定的，所以我们在存储数据的时候把对应信息存储下来方便后续读取。因为该部份对本文影响不大，因此没有展开。

2. next_record 字段
在记录头中这个显眼的「next_record」字段相信已经引起了你的注意，正如其字面意思，该字段表示的是当前记录与一下条记录的偏移量。换一个说法就是，该字段是一个指向下一条记录的指针。

所以我们可以看到，在 InnoDB 中所有的数据就是通过该字段串起来成了一个单链表。而 MySQL 优化手段也是基于此进行改造的。

上图是我经过简化后的示意图，我把一些与本篇无关的内容隐藏掉了，仅保留了比较关键的内容

InnoDB数据页

页是 InnoDB 管理存储空间的基本单位，一个页的大小一般是 16k。数据页中则存放着我们上面提到的一行行记录，现在我们知道记录之间是通过 next_record 字段串联形成一个单向链表。那么在一个数据页中要查找某条记录该怎么办呢？

最笨的办法是从第一条记录开始遍历一遍链表，那么第一条记录我们怎么知道是哪条呢？以及当数据很多时，遍历一遍的时间也是无法忽视的，MySQL是怎么优化的？下面我们来看一下 MySQL 中数据页的格式，如下图：

在上图中我们可以看到一个数据页中关键的几个东西：

1. 页号：页号是唯一的，如同身份证号码一样，InnoDB 通过页号来唯一定位一个页
2. 最小记录/最大记录：页面中的最小记录和最大记录，用于指向真实数据记录，相当于真实记录链表的头尾哨兵
3. 槽（slot）：页目录，用于快速定位页面中的记录，加速查找过程（通过二分查找）。
   1. 将所有正常的记录（包括最大/最小记录）划分为几个组，一个组对应槽中的一位（对应图中黄色范围）
   2. 每组记录的最后一条记录中的记录头中会有一个 n_owned 属性表示该组内共有几条记录
   3. 将每个组中最后一条记录在页面中的偏移量单独提取出来（就是槽中的每一位均指向每组记录中最大的那条记录）

页目录（槽）

比如现在图中有5条记录，InnoDB 会把他们分成2个组，第一组只有一个「最小记录」（也就是头哨兵），第二组则是剩余的4条记录，一共两个组。因此对应着2个槽，每个槽中存放每个组中最大的那条记录在页面中的地址偏移量（即指向最大记录的指针）。每个分组中的记录条数都有规定，规定如下：

1. 最小记录（头哨兵）所在的分组只能有一条记录
2. 最大记录（尾哨兵）所在的分组拥有的记录数只能在1～8条之间
3. 剩余的分组中记录的条数范围为4～8条之间

所以初始情况下只有最小/大记录，因此页目录（槽）中只有两个组。之后每插入一条记录，都会从页目录上找到对应记录的主键值比准备插入的主键值大，且差值最小（为了让主键顺序排列-从小到大）的槽，然后把该槽的 n_owned 值加一，表示添加了一条记录，直到该组记录中的记录数等于8个。8个后再插入则不满足第二条规则，因此会产生新的一个组，并将原有记录进行迁移，使得满足三条规则。

在数据页中定位记录

当前页面中记录太少，不好演示页目录如何加快查找速度的，为此我们往页面添加几条记录，添加后的数据页如下（为了清晰的展示槽与组之间的关系，我将记录之间的指针隐藏了，详细看上一张图片）：

因为记录的主键都是从小到大排列的，所以我们可以使用二分法快速查找记录，如图中所示一共有5个槽，接下来我们模拟一下在该表中找到「记录6」的过程：

1. 根据槽的信息，可以得到最低的槽 low = 0，最高的槽 high=4（也就是二分查找的初始边界）
2. 计算中间槽的位置：(0+4)/2 = 2，查看槽2对应记录为8，又因为 8 > 6，所以设置 high=2, low 保持不变
3. 重新计算中间槽的位置：(0+2)/2 = 1，查看槽1对应组最大记录的主键值为4；又因为 4 < 6,所以设置 low=1, high 保持不变
4. 因为 high-low = 1，所以确定主键值为6的记录在槽2对应的组中
5. 此时我们只需从槽1的最大记录开始遍历每条记录（也就是从槽2的开头遍历），便能很快找到「记录6」了。

上面我们已经介绍过，每个组中包含的记录条数最多是8条，所以遍历一个组中的记录代价是很小的。因此我们可以将上面的步骤再提炼一下，总结成在一个数据页中查找元素的步骤：

1. 在页目录中通过二分法确认记录所在的槽
2. 通过记录的 next_record 属性遍历该槽所在的组中的各个记录

至此，我们已经知道了如何在数据页中快速查找到一条记录，而将这一个个数据页连接起来便能是我们存储的所有数据了。那么如何才能高效的在这么多数据页中查找记录，接下来就轮到“索引同志”登场了。

B+树索引

我们知道一个数据页的大小是 16K，而我们业务中一个表的数据动辄就上G，显然一个数据页是无法装下我们的数据的。那么在一个表中的数据页是怎么链接起来的？我们回到查询一条记录的语句上，要在这么多数据页中找到一条记录，最笨的方法便是遍历所有的数据页，那么为什么要遍历所有的数据页呢？我们不能有个聪明点的方法吗？原因是因为数据页之间是没有规律的，我们并不知道搜索调节会匹配哪些页的记录（因为没有规律，所有的数据页都有可能存在），因此不得不遍历所有数据页。

那么如何快速定位到记录在哪些数据页中？我们还记得在数据页里面为了快速定位一条记录，我们为页中的数据划分了组，并且为此建立了一个页目录（槽）。同样的我们也可以想办法为了「快速定位记录所在的页」而建立一个目录，在建立这个目录的过程中需要满足这几个条件（页与页之间的规定）：

1. 下一个数据页中「真实记录」的主键值必须大于上一个页中「真实记录」的主键值（叶子节点）
2. 数据页之间通过前后指针相连
3. 给所有页建立一个目录项（内节点）

为此我们得到了一个简易版的索引方案，如下图：