解剖 Mutex

http://techsingular.net/?p=1932

新年前读到 Varnish 开发者 Poul-Henning 的一篇 blog《 The Tools We Work With 》，谈到他对 POSIX thread mutex 做了简单封装来实现「assert if I’m holding this mutex locked」功能。（这里说明一下，Poul-Henning 和本文所指的 mutex 是构建 critical region 而且能够切换线程的 running-wait 状态的锁。在有的 framework 里这种机制有其它名称，如 Cocoa 的 NSLock。本文称进入和离开 critical region 的操作称为 lock/unlock mutex，处于 critical region 中的状态为 holding mutex。）

我对 Poul-Henning 的说法既感兴趣又怀疑，对数据进行多线程并发访问是非常容易出问题的。以前曾经有个著名的只在 rare-path 加锁的 double-checked lock 的错误例子。Varnish 的 assertion 对 mutex 本身相关的（而非它所保护的）数据进行多线程访问。这需要它的 mutex 封装里再提供某种同步机制。Varnish 有没有正确提供这种保护？或者是否会造成性能问题乃至于死锁？为了搞清这些疑问，我下载了一份 Varnish 代码。其中的 lock/unlock/assert 代码基本如下 [1]：

实际代码证实了我的担忧。Lck__Assert() 对 owner 和 held 的访问并无保护。修正这个错误要在 sturct ilck 里定义另一个 mutex（意味着整个系统的 mutex 数目加倍），或者使用一个新的全局 mutex（意味着整个系统的 mutex 竞争急剧增加）。如果仅仅是一个 debug assertion 的需要倒也不是大问题。可是仔细想想，实现 reentrant mutex 也需要类似的功能。因此肯定应该有更好的方法。最后我在 Stackoverflow.com 上得到了一个方案，修改 unlock 方法如下：

我给 Poul-Henning 发信说明这个问题，他同意了我的分析和补救 [2]，同时指出了一个我没有意识到的问题。一开始我错以为 owner 是个整数 ID，给出的方案是在 Lck__Unlock() 中将其设置为某个非法值（比如 0 或者 -1）。Poul-Henning 指出 thread_t 是平台相关的不透明类型，没有非法值的定义，他提出用 memset() 清零来作为目前的方案，尽管仍然有下面的缺陷：

• 全 0 的 thread_t 可能在某些平台上是合法的线程 ID。
• 尽管在没有 hold mutex 的情况下 owner 几乎不可能等于当前线程 ID，但是由于没有保护，Lck__Assert() 中读取的 thread_t 有可能是一个被其它线程部分修改的受损数据 (corrupted data) 。在某些平台上也许 pthread_equal() 不能安全的处理这种 ID。
• 不能完全排除在某些罕见情况下一个部分受损的 owner 变量的值恰好等于当前线程 ID。

给 mutex 提供额外的功能并不是简单的任务，给 POSIX thread mutex 这样的跨平台机制扩展功能就更难了。我觉定深入研究一下 mutex，以及在多大程度上能对它们进行跨平台的扩展。

纯软件实现

每个学习多线程编程的人一开始就要接触 critical region 的概念 —— 保证至多一个线程进入的代码区域。经典操作系统教材《 Operating System: Design and Implementation, 2nd Edition 》 [3] 中给出了一个叫做 Peterson 方法的纯软件 critical region 实现（为了描述简单，给出的例子只支持两个线程的情况）[4]：

Peterson 方法解释了线程抢占问题，但它只是一个假定各线程严格顺序执行的教学例子，在今天的计算机上是不能正常工作的，因为编译器和 CPU 采取下列措施优化程序的性能：

• 编译器生成的优化代码和源代码并非按顺序对应。
• CPU 在运行过程中以提升性能为目的打乱指令的执行顺序。
• CPU 在运行过程中通过流水线对同一指令序列的不同部分并行执行。
• 每个 CPU 有自己的局部 cache，没有固定机制保证局部 cache 和主内存同步的顺序和时延。

当然编译器和 CPU 进行这些优化乱序的时候不能任意而为。为了在最大程度上延续这些技术出现之前的编程方式，这些优化机制保证在「单一线程内」的运行结果仍然和顺序执行等效。「顺序等效」确保在 Lck__Unlock() 中对owner 清零可以让 assertion 正确工作，因为只有当 Lck__Assert() 和 lock 处于同一线程内，并且处于 critical region 内，owner 才等于当前线程 ID。

由于不改变编程方式，无需程序员介入，这种「等效保证」和 CPU 频率的提升一起被视为前多核时代的性能「免费午餐」。但是「顺序等效」不能扩展到多线程，如果没有显式求助硬件的保证：

• 一个线程的执行在其它线程看来并非严格顺序执行。
• 一个线程对内存的改动不能立即对其它线程可见。
• 一个线程对内存的改动对其它线程的可见顺序不一定和改动顺序一致。

在上面的 Peterson 方法代码中，两个线程在第 12 行可能同时看到while 的判定条件为 FALSE，因为变量 turn 和 interested 可能分别在各 CPU 的局部 cache 中有未经同步的拷贝。在「唯一线程进入」的基础上，今天操作系统的 critical region 要提供更多功能，它要保证：

• 最多只有一个线程能进入 critical region；
• 编译器不进行跨越 critical region 边界的乱序优化；
• CPU 不进行跨越 critical region 边界的乱序执行；
• 所有 CPU 的局部 cache 在 critical region 的边界和主内存同步。

简单 Mutex

为了保证 CPU 和主内存之间的同步，硬件提供了一套 inter-processor communication 机制。这些机制是为了像 kernel 这样的高性能底层代码设计的，和 critical region 的基本概念有一定距离。比如 read/write barrier 只是保证了同步的时序，不保证时延。最接近 critical region 的机制是「总线锁」[5]，它保证了上面列出的 critical region 四条要求的后三条。但总线锁的持续时间只是某些特定的单条指令 [6]，不能构建真正的 critical region。操作系统在它的基础上实现了一套 lock/unlock mutex 的操作。Mutex 的数据结构是一个 CPU 总线锁支持原子化修改的整数类型和一个线程等待队列。Lock 操作如下（或者等效）：

1. 执行一个原子操作，对整数减一并返回结果。
2. 如果结果为 -1，说明 critical region 内没有其它线程，继续执行进入 critical region。
3. 如果结果小于 -1，将当前线程放入等待队列。

Unlock 操作如下：

1. 执行一个原子操作，对整数加一并返回结果。
2. 如果结果为 0，说明没有其它线程被阻塞。
3. 如果结果小于 0，将等待队列中的一个线程执行放入 kernel scheduler 的 ready 队列（唤醒该线程）。

这种简单的 mutex 不是大多数应用程序使用的 rentrant mutex，和后者有如下区别，

• 同一线程试图两次 lock 一个简单 mutex 会导致死锁。而 reentrant mutex 可以被同一线程 lock 多次。
• 在同一线程中对 reentrant mutex 的线程必须成对出现。而简单 mutex 没有这个限制。
• 由于第二点，处于一个 reentrant mutex 的 critical region 中的线程称为这个 mutex 的 owner。而简单 mutex 没有 owner。

简单 mutex 在 Linux 和 BSD 的 kernel 代码中叫做 semaphore。Reentrant mutex 在简单 mutex 的基础之上实现。

正是由于 reentrant mutex 的 lock 和 unlock 操作必须在同一线程中成对出现，Varnish 的 Lck__Assert() 才能（在加入我的修改之后）利用单线程的「顺序等效」保证 owner 的状态能正确反映 holding mutex 的状态。这里我们会发现 Varnish 的 assertion 有一个基本语义的问题，它使用了 owner 的概念，要求 lock/unlock 在同一线程成对出现，这表明它针对的是 reentrant mutex。但是在它的 lock/unlock 操作中没有处理 holding mutex 的嵌套层数。这是 Varnish 的另一个错误，它没有显现出来也许是因为在 Varnish 中 reentrant mutex 并不实际发生嵌套 lock。或者也可以说一个有 owner 的 mutex 只是要求 lock/unlock 处于同一线程，并不一定非要支持 reentrant，但我认为这样复杂化 mutex 的分类并无必要。最好还是把 owner 和 reentrant 等同起来概念比较明晰。好在明确这个问题之后不影响其它讨论。对嵌套层次的支持也可以很容易地加入到 Varnish 的 assertion 中。

Reentrant Mutex

到目前为止，我们有了一个利用「等效原理」基本可以工作的「assert if I’m holding this (reentrant) mutex locked」机制，也回顾了简单 mutex 的原理。理论上可以利用二者来实现 reentrant mutex。还有这么几个问题没有得到确定的回答：

• 类型 thread_t 是一个复杂的结构还是一个简单类型（整数/指针）？
• POSIX 库能否保证目前 Varnish 的 assertion 正常工作？
• 如果 thread_t 是一个复杂类型的话，POSIX 库很可能需要一个 directory 来维护这个复杂类型和内核的 thread ID 之间的联系。那么该 directory 也需要某些同步机制来保护（比如 kernel semaphore）。那就意味着 pthread_self() 这样的方法也有相当可观的性能开销，在这种情况下利用「等效原理」避免 mutex 的性能提升是否有意义？
• POSIX thread 库是否真的利用「顺序等效」实现 reentrant mutex？
• 如果不是，POSIX thread 的实现方式和「等效原则」相比性能如何？

由于 POSIX 是跨平台标准，所以这些问题不可能得到完全解答。最后的答案只限于 OS X [7]（很大程度上适用于所有 BSD 系统）。

在 OS X 上 thread_t 是一个指针。pthread_self() 从 GS 寄存器返回该指针。GS 是 kernel 维护 per-thread 数据的寄存器。Per-thread 数据在各自线程内遵循「顺序等效」，无需同步机制。这解决了前三个问题 —— Varnish 的 assertion 可以在 OS X 上正常工作， pthread_equal() 也不会有性能损耗。更进一步说，利用通用的 per-thread 数据机制可以更有效的利用「顺序等效」原理。比如可以维护当前线程 hold 的所有 mutex。POSIX 提供 per-thread 数据的通用接口，如 pthread_key_create()。 相比之下，目前 Varnish 利用「顺序等效」原理只是一种 ad-hoc 的方式。

接下来，POSIX thread 库利用 thread_t 的成员来实现 reentrant mutex 功能。在 OS X 的 pthread_mutex_unlock() 并没有类似 Lck__Assertion() 对 owner 清零的操作，只有类似将 held 设置为 FALSE 的操作。它并没有采用 ad-hoc 的「顺序等效」来实现「assert if I’m holding this mutex locked」，也没有采用 per-thread 数据。在 POSIX thread mutex 里，除了用来创建 critical region 的底层 semaphore 之外，还有一个专门保护 thread_t 成员的「锁」。这个锁不是 mutex 而是 spinlock。Spinlock 的语义类似简单 (non-reentrant) mutex (semaphore)，不同之处在于线程竞争时后入线程不会被放入等待队列，而是进入空循环，所以在 critical region 很短的时候性能开销没有 mutex 那么大。

从 OS X 的实现来看，对性能开销的顾虑并没有我一开始担心的那么大。比较之下，我提出的修正 Varnish assertion 的方式太 ad-hoc，完全可以采用更可靠的 spinlock 或者 per-thread 数据。

脚注：

1. 为了叙述清楚我删除和修改了一些无关代码。
2. 我提议的修改 2011 年 12 月 28 日进入 Varnish 的 code base。
3. 62 页图 2-9。这是我在大学买的第一本英文影印版书。Linus 编写 Linux kernel 之前通读了此书第一版。
4. 由于采用空循环的 busy wait 而非线程的挂起，这个机制不是 mutex。
5. 《Intel® 64 and IA-32 Architectures Developer’s Manual: Vol. 3A》，第 8.1.2.2 节：Software Controlled Bus Locking。
6. 同上。
7. Apple 的 open source 页面。